* [PATCH v2] phy: sun4i: check PMU presence when poking unknown bit of pmu
From: Kishon Vijay Abraham I @ 2016-11-05 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41f43381-c1bb-2f69-5f99-ac5cebf651ea@redhat.com>
On Friday 28 October 2016 11:45 PM, Hans de Goede wrote:
> Hi,
>
> On 28-10-16 18:27, Icenowy Zheng wrote:
>> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
>> The code that poke some unknown bit of PMU for H3/A64 didn't check
>> the PHY, and will cause kernel oops when PHY 0 is used.
>>
>> This patch will check whether the pmu is not NULL before poking.
>>
>> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Patch LGTM too:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
merged, thanks.
-Kishon
>
> Regards,
>
> Hans
>
>
>> ---
>> drivers/phy/phy-sun4i-usb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
>> index b9342a2..fec34f5 100644
>> --- a/drivers/phy/phy-sun4i-usb.c
>> +++ b/drivers/phy/phy-sun4i-usb.c
>> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>> return ret;
>> }
>>
>> - if (data->cfg->enable_pmu_unk1) {
>> + if (phy->pmu && data->cfg->enable_pmu_unk1) {
>> val = readl(phy->pmu + REG_PMU_UNK1);
>> writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>> }
>>
^ permalink raw reply
* [PATCH] drm/sun4i: Fix error handling
From: Christophe JAILLET @ 2016-11-05 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102181444.hfrh6fcr2a5oe5n4@lukather>
Le 02/11/2016 ? 19:14, Maxime Ripard a ?crit :
> Hi,
>
> On Sun, Oct 30, 2016 at 12:53:02PM +0100, Christophe JAILLET wrote:
>> BTW, memory allocation in 'sun4i_layers_init()' looks spurious, especially
>> the use of 'layer' in the for loop.
>> Just my 2 cents.
> What do you mean by it's spurious?
Hi Maxime,
what I mean is:
> struct sun4i_layer **sun4i_layers_init(struct drm_device *drm)
> {
> struct sun4i_drv *drv = drm->dev_private;
> struct sun4i_layer **layers;
> int i;
>
> layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
> sizeof(**layers), GFP_KERNEL);
Here, we allocate some memory for ARRAY_SIZE(sun4i_backend_planes) (i.e.
2) 'struct sun4i_layer'.
We do not allocate some space for some pointers but for some structure.
Also, these structures are zeroed and seem to never be initialized by
anything else.
> if (!layers)
> return ERR_PTR(-ENOMEM);
>
> /*
> * The hardware is a bit unusual here.
> *
> * Even though it supports 4 layers, it does the composition
> * in two separate steps.
> *
> * The first one is assigning a layer to one of its two
> * pipes. If more that 1 layer is assigned to the same pipe,
> * and if pixels overlaps, the pipe will take the pixel from
> * the layer with the highest priority.
> *
> * The second step is the actual alpha blending, that takes
> * the two pipes as input, and uses the eventual alpha
> * component to do the transparency between the two.
> *
> * This two steps scenario makes us unable to guarantee a
> * robust alpha blending between the 4 layers in all
> * situations. So we just expose two layers, one per pipe. On
> * SoCs that support it, sprites could fill the need for more
> * layers.
> */
The comment make me think that this driver (and this function) only
handles 2 layers ("So we just expose two layers"), which is consistent
with ARRAY_SIZE(sun4i_backend_planes) (i.e. 2)
So I would expect that only 2 'struct sun4i_layer' to be allcoated
> for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
> const struct sun4i_plane_desc *plane = &sun4i_backend_planes[i];
> struct sun4i_layer *layer = layers[i];
Here, we take the address of one of the 2 structure allocated above.
This is overridden, just the line after.
>
> layer = sun4i_layer_init_one(drm, plane);
'sun4i_layer_init_one()' looks() like:
struct sun4i_layer *layer;
layer = devm_kzalloc(drm->dev, sizeof(*layer), GFP_KERNEL);
...
return layer;
So we once more allocate some 'struct sun4i_layer'
BUT, the corresponding address is stored into the 'layer' variable, and
finally seems to get lost and no reference is kept of this. (i.e.
'layers' (with an s) is left unchanged)
> if (IS_ERR(layer)) {
> dev_err(drm->dev, "Couldn't initialize %s plane\n",
> i ? "overlay" : "primary");
> return ERR_CAST(layer);
> };
>
> DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
> i ? "overlay" : "primary", plane->pipe);
> regmap_update_bits(drv->backend->regs,
SUN4I_BACKEND_ATTCTL_REG0(i),
> SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK,
> SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
>
> layer->id = i;
> };
>
> return layers;
> }
So, 4 'struct sun4i_layer' have been allocated. 2 in
'sun4i_layers_init()' and 2 in 'sun4i_layer_init_one()' (once at a time,
but called twice)
What looks spurious to me is either:
- 'struct sun4i_layer *layer = layers[i];' which should just be
'struct sun4i_layer *layer;'
or
- 'layers' (with an s) should be an array of pointers and the
addresses returned by 'sun4i_layer_init_one()' should be saved there.
I don't know at all this driver, so I'm maybe completely wrong.
What I would have expected would be something like: (un-tested, just to
give an idea)
==============8<================================================
@@ -133,9 +133,9 @@ struct sun4i_layer **sun4i_layers_init(struct
drm_device *drm)
struct sun4i_layer **layers;
int i;
layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
- sizeof(**layers), GFP_KERNEL);
+ sizeof(*layers), GFP_KERNEL);
if (!layers)
return ERR_PTR(-ENOMEM);
/*
@@ -160,16 +160,17 @@ struct sun4i_layer **sun4i_layers_init(struct
drm_device *drm)
* layers.
*/
for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
const struct sun4i_plane_desc *plane = &sun4i_backend_planes[i];
- struct sun4i_layer *layer = layers[i];
+ struct sun4i_layer *layer;
layer = sun4i_layer_init_one(drm, plane);
if (IS_ERR(layer)) {
dev_err(drm->dev, "Couldn't initialize %s plane\n",
i ? "overlay" : "primary");
return ERR_CAST(layer);
};
+ layers[i] = layer;
DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
i ? "overlay" : "primary", plane->pipe);
regmap_update_bits(drv->backend->regs,
SUN4I_BACKEND_ATTCTL_REG0(i),
Best regards,
CJ
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Shawn Guo @ 2016-11-05 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+YopHVNxh4Vi5o1d=S3FFkoz45dNmgHMgs1sAQqaL77A@mail.gmail.com>
On Fri, Nov 04, 2016 at 12:44:21PM -0500, Adam Ford wrote:
> >> +&iomuxc {
> >> + imx6qdl-logicpd-baseboard {
> >> +
> >
> > Drop this container node and put the following pinctrl nodes directly
> > under &iomuxc.
> >
>
> Like the regulators above, if I remove this connector, the system
> won't boot. I compared both the regulator and the iomuxc containers
> in this device tree with other imx6q boards, and I seem to be
> consistent with what other boards are doing.
You might want to rebase the patch to latest mainline like v4.9-rc3 and
test first.
Shawn
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: imx28: Fix build warnings with W=1
From: Shawn Guo @ 2016-11-05 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DbiHV-uR9bpdEFTfzDRXuWDao_RYxDCPJ1N=FuF4VCyQ@mail.gmail.com>
On Fri, Nov 04, 2016 at 06:51:06PM -0200, Fabio Estevam wrote:
> Hi Shawn,
>
> On Thu, Sep 8, 2016 at 11:03 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> > On Mon, Sep 05, 2016 at 04:27:50PM -0300, Fabio Estevam wrote:
> >> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
> >> index 0ebbc83..b4d4dbb 100644
> >> --- a/arch/arm/boot/dts/imx28-tx28.dts
> >> +++ b/arch/arm/boot/dts/imx28-tx28.dts
> >> @@ -35,7 +35,8 @@
> >> usbotg = &usb0;
> >> };
> >>
> >> - memory {
> >> + memory at 0 {
> >> + device_type = "memory";
> >> reg = <0 0>; /* will be filled in by U-Boot */
> >
> > I'm curious to know if the unit-address will be fixed up or not when
> > 'reg' property gets updated by U-Boot.
>
> Should I resend this series and keep imx28-tx28.dts unmodified?
Yeah, probably the best thing we can do.
Shawn
^ permalink raw reply
* [PATCH v2 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Shawn Guo @ 2016-11-05 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478109604-18323-1-git-send-email-Frank.Li@nxp.com>
On Wed, Nov 02, 2016 at 01:00:03PM -0500, Frank Li wrote:
> i.MX6QP added new reigster bit PROFILE_SEL in MADPCR0.
s/reigster/register
> need set it at perf start.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
We probably need a 'for' in patch subject after 'support'?
> ---
> V1 to V2: remove fsl_mmdc_devtype
>
> arch/arm/mach-imx/mmdc.c | 38 ++++++++++++++++++++++++++++++++------
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
> index d82d14c..032cbe0 100644
> --- a/arch/arm/mach-imx/mmdc.c
> +++ b/arch/arm/mach-imx/mmdc.c
> @@ -44,6 +44,7 @@
> #define DBG_RST 0x2
> #define PRF_FRZ 0x4
> #define CYC_OVF 0x8
> +#define PROFILE_SEL 0x10
>
> #define MMDC_MADPCR0 0x410
> #define MMDC_MADPSR0 0x418
> @@ -55,10 +56,29 @@
>
> #define MMDC_NUM_COUNTERS 6
>
> +#define FSL_MMDC_QUIRK_PROFILE_SEL 0x1
> +
What about naming it MMDC_FLAG_PROFILE_SEL?
> #define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>
> static int ddr_type;
>
> +struct fsl_mmdc_devtype_data {
> + int driver_data;
> +};
What about the following?
struct imx_mmdc_data {
unsigned int flags;
};
> +
> +static struct fsl_mmdc_devtype_data imx6q_data = {
> +};
> +
> +static struct fsl_mmdc_devtype_data imx6qp_data = {
> + .driver_data = FSL_MMDC_QUIRK_PROFILE_SEL,
> +};
Have a const for better?
> +
> +static const struct of_device_id imx_mmdc_dt_ids[] = {
> + { .compatible = "fsl,imx6q-mmdc", .data = (void *)&imx6q_data},
> + { .compatible = "fsl,imx6qp-mmdc", .data = (void *)&imx6qp_data},
> + { /* sentinel */ }
> +};
> +
> #ifdef CONFIG_PERF_EVENTS
>
> static DEFINE_IDA(mmdc_ida);
> @@ -83,6 +103,7 @@ struct mmdc_pmu {
> struct device *dev;
> struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
> struct hlist_node node;
> + struct fsl_mmdc_devtype_data *devtype_data;
mmdc_data
> };
>
> /*
> @@ -307,6 +328,7 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
> struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> void __iomem *mmdc_base, *reg;
> + int val;
Shouldn't it be u32 for better?
Shawn
>
> mmdc_base = pmu_mmdc->mmdc_base;
> reg = mmdc_base + MMDC_MADPCR0;
> @@ -321,7 +343,12 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
> local64_set(&hwc->prev_count, 0);
>
> writel(DBG_RST, reg);
> - writel(DBG_EN, reg);
> +
> + val = DBG_EN;
> + if (pmu_mmdc->devtype_data->driver_data & FSL_MMDC_QUIRK_PROFILE_SEL)
> + val |= PROFILE_SEL;
> +
> + writel(val, reg);
> }
>
> static int mmdc_pmu_event_add(struct perf_event *event, int flags)
> @@ -436,6 +463,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
> char *name;
> int mmdc_num;
> int ret;
> + const struct of_device_id *of_id =
> + of_match_device(imx_mmdc_dt_ids, &pdev->dev);
>
> pmu_mmdc = kzalloc(sizeof(*pmu_mmdc), GFP_KERNEL);
> if (!pmu_mmdc) {
> @@ -450,6 +479,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
> name = devm_kasprintf(&pdev->dev,
> GFP_KERNEL, "mmdc%d", mmdc_num);
>
> + pmu_mmdc->devtype_data = (struct fsl_mmdc_devtype_data *)of_id->data;
> +
> hrtimer_init(&pmu_mmdc->hrtimer, CLOCK_MONOTONIC,
> HRTIMER_MODE_REL);
> pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
> @@ -524,11 +555,6 @@ int imx_mmdc_get_ddr_type(void)
> return ddr_type;
> }
>
> -static const struct of_device_id imx_mmdc_dt_ids[] = {
> - { .compatible = "fsl,imx6q-mmdc", },
> - { /* sentinel */ }
> -};
> -
> static struct platform_driver imx_mmdc_driver = {
> .driver = {
> .name = "imx-mmdc",
> --
> 2.5.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 00/22] mtd: nand: return error code of nand_scan(_ident, _tail) on error
From: Marek Vasut @ 2016-11-05 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478256190-7452-1-git-send-email-yamada.masahiro@socionext.com>
On 11/04/2016 11:42 AM, Masahiro Yamada wrote:
>
> nand_scan(), nand_scan_ident(), nand_scan_tail() return
> an appropriate negative value on error.
>
> Most of drivers return the value from them on error,
> but some of them return the fixed error code -ENXIO
> (and a few return -ENODEV).
>
> This series make those drivers return more precise error code.
>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Nice cleanup, thanks!
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH V2 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Shawn Guo @ 2016-11-05 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478109604-18323-2-git-send-email-Frank.Li@nxp.com>
On Wed, Nov 02, 2016 at 01:00:04PM -0500, Frank Li wrote:
> mmdc of i.MX6QP are little difference with i.MX6Q.
> added new compatible stream fsl,imx6qp-mmdc
s/stream/string
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> No change for this patch.
> suspend resume code need fsl,imx6q-mmdc
You should probably add such info into commit log, e.g. although
MMDC has a slightly different programming model between imx6q and imx6qp
in terms of perf support, it's exactly same for suspend support, so we
have fsl,imx6q-mmdc here to save patching suspend driver with the new
compatible.
>
> arch/arm/boot/dts/imx6qp.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
> index 886dbf2..e0fdd0f 100644
> --- a/arch/arm/boot/dts/imx6qp.dtsi
> +++ b/arch/arm/boot/dts/imx6qp.dtsi
> @@ -85,5 +85,12 @@
> pcie: pcie at 0x01000000 {
> compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
> };
> +
> + aips-bus at 02100000 {
> + mmdc0: mmdc at 021b0000 { /* MMDC0 */
> + compatible = "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc";
> + reg = <0x021b0000 0x4000>;
> + };
> + };
It seems that pcie already went wrong, but please still try to add
devices in order of unit-address.
Shawn
> };
> };
> --
> 2.5.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/1] ARM: dmaengine: sun6i: share the dma driver with sun50i
From: Hao Zhang @ 2016-11-05 8:05 UTC (permalink / raw)
To: linux-arm-kernel
Add soc a64 dma support.
Signed-off-by: Hao Zhang <hao5781286@gmail.com>
---
drivers/dma/sun6i-dma.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 8346199..00fcfc7 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1028,11 +1028,23 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_vchans = 34,
};
+/*
+ * The A64 has 8 physical channels, a maximum DRQ port id of 27,
+ * and a total of 38 usable source and destination endpoints.
+ */
+
+static struct sun6i_dma_config sun50i_a64_dma_cfg = {
+ .nr_max_channels = 8,
+ .nr_max_requests = 27,
+ .nr_max_vchans = 38,
+};
+
static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
{ .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
{ .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
{ .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
+ { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun6i_dma_match);
@@ -1110,6 +1122,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)
sdc->slave.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
+
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "allwinner,sun50i-a64-dma")) {
+ sdc->slave.src_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+ sdc->slave.dst_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
+ }
+
sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
BIT(DMA_MEM_TO_DEV);
sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
--
2.7.4
^ permalink raw reply related
* [PATCH v2] ARM: dts: imx53-qsb: Fix regulator constraints
From: Shawn Guo @ 2016-11-05 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477580804-1423-1-git-send-email-fabio.estevam@nxp.com>
On Thu, Oct 27, 2016 at 01:06:44PM -0200, Fabio Estevam wrote:
> Since commit fa93fd4ecc9c ("regulator: core: Ensure we are at least in
> bounds for our constraints") the imx53-qsb board populated with a Dialog
> DA9053 PMIC fails to boot:
>
> LDO3: Bringing 3300000uV into 1800000-1800000uV
>
> The LDO3 voltage constraints passed in the device tree do not match
> the valid range according to the datasheet, so fix this accordingly to
> allow the board booting again.
>
> While at it, fix the other voltage constraints as well.
>
> Cc: <stable@vger.kernel.org> # 4.7.x
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
From: Shawn Guo @ 2016-11-05 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477882709-2518-1-git-send-email-peter.chen@nxp.com>
On Mon, Oct 31, 2016 at 10:58:28AM +0800, Peter Chen wrote:
> We need to change trimming value (as a percentage) of the 17.78mA TX
> reference current for better signal quality. With this change, we
> can patch the eye-diagram test on this board.
s/patch/pass? I just want to confirm this is a typo, and can fix it up
when applying.
Shawn
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/boot/dts/imx6sx-sdb.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi b/arch/arm/boot/dts/imx6sx-sdb.dtsi
> index 85f56a5..4933c56 100644
> --- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
> +++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
> @@ -317,6 +317,14 @@
> status = "okay";
> };
>
> +&usbphy1 {
> + fsl,tx-d-cal = <106>;
> +};
> +
> +&usbphy2 {
> + fsl,tx-d-cal = <106>;
> +};
> +
> &usdhc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc2>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 1/3] ARM: imx6u: add imx6ull support
From: Shawn Guo @ 2016-11-05 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477969343-19887-2-git-send-email-peter.chen@nxp.com>
On Tue, Nov 01, 2016 at 11:02:21AM +0800, Peter Chen wrote:
> It is the 10th processor in the well-known imx6 series, and derived
> from imx6ul but cost optimized. The more information about imx6ull
> can be found at:
>
> http://www.nxp.com/products/microcontrollers-and-processors/
> arm-processors/i.mx-applications-processors/i.mx-6-processors
> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
> :i.MX6ULL
>
> In this patch, it moves common dts between imx6ul* and imx6ull* as
> new files named imx6u*, and the specific part for imx6ul and imx6ull
> are individual file.
No. That only helps churn the tree and git history. Please keep using
imx6ul.dtsi and simply have it be included by imx6ull.dtsi.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/imx6u-14x14-evk.dts | 475 ++++++++++++++++
> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487 +++++++++++++++++
> arch/arm/boot/dts/imx6u.dtsi | 942 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479 +---------------
> arch/arm/boot/dts/imx6ul.dtsi | 936 +------------------------------
> arch/arm/boot/dts/imx6ull-14x14-evk.dts | 17 +
> arch/arm/boot/dts/imx6ull-pinfunc.h | 57 ++
> arch/arm/boot/dts/imx6ull.dtsi | 10 +
> 9 files changed, 1993 insertions(+), 1413 deletions(-)
> create mode 100644 arch/arm/boot/dts/imx6u-14x14-evk.dts
> create mode 100644 arch/arm/boot/dts/imx6u-14x14-evk.dtsi
> create mode 100644 arch/arm/boot/dts/imx6u.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
> create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..3d6e199 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -423,7 +423,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> imx6ul-pico-hobbit.dtb \
> imx6ul-tx6ul-0010.dtb \
> imx6ul-tx6ul-0011.dtb \
> - imx6ul-tx6ul-mainboard.dtb
> + imx6ul-tx6ul-mainboard.dtb \
> + imx6ull-14x14-evk.dtb
> dtb-$(CONFIG_SOC_IMX7D) += \
> imx7d-cl-som-imx7.dtb \
> imx7d-colibri-eval-v3.dtb \
> diff --git a/arch/arm/boot/dts/imx6u-14x14-evk.dts b/arch/arm/boot/dts/imx6u-14x14-evk.dts
> new file mode 100644
> index 0000000..ba8614c
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6u-14x14-evk.dts
> @@ -0,0 +1,475 @@
> +/*
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + */
For new DT files, please consider to use GPL/X11 dual license. You
should be able to find a lot of examples in arch/arm/boot/dts.
<snip>
> diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h
> new file mode 100644
> index 0000000..fca0036
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + */
> +
> +#ifndef __DTS_IMX6ULL_PINFUNC_H
> +#define __DTS_IMX6ULL_PINFUNC_H
> +
> +#include "imx6ul-pinfunc.h"
> +/*
> + * The pin function ID is a tuple of
> + * <mux_reg conf_reg input_reg mux_mode input_val>
> + */
> +#define MX6UL_PAD_ENET2_RX_DATA0__EPDC_SDDO08 0x00E4 0x0370 0x0000 0x9 0x0
Can we name these imx6ull specific defines MX6ULL_xxx, so that we know
they should only be used in imx6ull specific dts?
> +#define MX6UL_PAD_ENET2_RX_DATA1__EPDC_SDDO09 0x00E8 0x0374 0x0000 0x9 0x0
> +#define MX6UL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x0000 0x9 0x0
> +#define MX6UL_PAD_ENET2_TX_DATA0__EPDC_SDDO11 0x00F0 0x037C 0x0000 0x9 0x0
> +#define MX6UL_PAD_ENET2_TX_DATA1__EPDC_SDDO12 0x00F4 0x0380 0x0000 0x9 0x0
> +#define MX6UL_PAD_ENET2_TX_EN__EPDC_SDDO13 0x00F8 0x0384 0x0000 0x9 0x0
> +#define MX6UL_PAD_ENET2_TX_CLK__EPDC_SDDO14 0x00FC 0x0388 0x0000 0x9 0x0
> +#define MX6UL_PAD_ENET2_RX_ER__EPDC_SDDO15 0x0100 0x038C 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_CLK__EPDC_SDCLK 0x0104 0x0390 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_ENABLE__EPDC_SDLE 0x0108 0x0394 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_HSYNC__EPDC_SDOE 0x010C 0x0398 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_VSYNC__EPDC_SDCE0 0x0110 0x039C 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_RESET__EPDC_GDOE 0x0114 0x03A0 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA00__EPDC_SDDO00 0x0118 0x03A4 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA01__EPDC_SDDO01 0x011C 0x03A8 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA02__EPDC_SDDO02 0x0120 0x03AC 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA03__EPDC_SDDO03 0x0124 0x03B0 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA04__EPDC_SDDO04 0x0128 0x03B4 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA05__EPDC_SDDO05 0x012C 0x03B8 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA06__EPDC_SDDO06 0x0130 0x03BC 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA07__EPDC_SDDO07 0x0134 0x03C0 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA14__EPDC_SDSHR 0x0150 0x03DC 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA15__EPDC_GDRL 0x0154 0x03E0 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x0000 0x9 0x0
> +#define MX6UL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x0000 0x9 0x0
> +
Why this new line?
Shawn
> +#define MX6UL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_VSYNC__ESAI_TX4_RX1 0x01DC 0x0468 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_HSYNC__ESAI_TX1 0x01E0 0x046C 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA00__ESAI_TX_HF_CLK 0x01E4 0x0470 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA01__ESAI_RX_HF_CLK 0x01E8 0x0474 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA02__ESAI_RX_FS 0x01EC 0x0478 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA03__ESAI_RX_CLK 0x01F0 0x047C 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0
> +#define MX6UL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0
> +
> +#endif /* __DTS_IMX6ULL_PINFUNC_H */
> diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
> new file mode 100644
> index 0000000..afd9796
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ull.dtsi
> @@ -0,0 +1,10 @@
> +/*
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "imx6u.dtsi"
> +#include "imx6ull-pinfunc.h"
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Shawn Guo @ 2016-11-05 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477969343-19887-4-git-send-email-peter.chen@nxp.com>
On Tue, Nov 01, 2016 at 11:02:23AM +0800, Peter Chen wrote:
> From: Bai Ping <ping.bai@nxp.com>
>
> imx6ull is the derived SoC from imx6ul
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> drivers/clk/imx/clk-imx6ul.c | 74 +++++++++++++++++++++++++++-----
> include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
> 2 files changed, 77 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
> index d1d7787..ceb99a7 100644
> --- a/drivers/clk/imx/clk-imx6ul.c
> +++ b/drivers/clk/imx/clk-imx6ul.c
> @@ -64,6 +64,11 @@ static const char *perclk_sels[] = { "ipg", "osc", };
> static const char *lcdif_sels[] = { "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> static const char *csi_sels[] = { "osc", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
> static const char *sim_sels[] = { "sim_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> +/* epdc_pre_sels, epdc_sels, esai_sels only exists on i.MX6ULL */
> +static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg", "pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd2_508m", };
> +static const char *esai_sels[] = { "pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg", };
> +static const char *epdc_sels[] = { "epdc_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
> +
The new line is not needed. There is already one below.
>
> static struct clk *clks[IMX6UL_CLK_END];
> static struct clk_onecell_data clk_data;
<snip>
> diff --git a/include/dt-bindings/clock/imx6ul-clock.h b/include/dt-bindings/clock/imx6ul-clock.h
> index fd8aee8..563fd5b 100644
> --- a/include/dt-bindings/clock/imx6ul-clock.h
> +++ b/include/dt-bindings/clock/imx6ul-clock.h
> @@ -236,6 +236,19 @@
> #define IMX6UL_CLK_PLL3_120M 223
> #define IMX6UL_CLK_KPP 224
>
> -#define IMX6UL_CLK_END 225
> +/* For i.MX6ULL */
> +#define IMX6UL_CLK_ESAI_PRED 225
> +#define IMX6UL_CLK_ESAI_PODF 226
> +#define IMX6UL_CLK_ESAI_EXTAL 227
> +#define IMX6UL_CLK_ESAI_MEM 228
> +#define IMX6UL_CLK_ESAI_IPG 229
> +#define IMX6UL_CLK_DCP_CLK 230
> +#define IMX6UL_CLK_EPDC_PRE_SEL 231
> +#define IMX6UL_CLK_EPDC_SEL 232
> +#define IMX6UL_CLK_EPDC_PODF 233
> +#define IMX6UL_CLK_EPDC_ACLK 234
> +#define IMX6UL_CLK_EPDC_PIX 235
> +#define IMX6UL_CLK_ESAI_SEL 236
Can we have these imx6ull only clocks named after IMX6ULL_xxx?
Shawn
> +#define IMX6UL_CLK_END 237
>
> #endif /* __DT_BINDINGS_CLOCK_IMX6UL_H */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v6 7/7] arm64: dts: NS2: add AMAC ethernet support
From: Sergei Shtylyov @ 2016-11-05 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104163024.GA6128@broadcom.com>
On 11/4/2016 7:30 PM, Jon Mason wrote:
>>> Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
>>> tree
>>>
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>> arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +++++
>>> arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 ++++++++++++
>>> 2 files changed, 17 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
>>> index b09f3bc..c4d5442 100644
>>> --- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
>>> +++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
>>> @@ -56,6 +56,10 @@
>>> };
>>> };
>>>
>>> +&enet {
>>> + status = "ok";
>>
>> The spec dictates it should be "okay" (although "ok" is also recognized).
>
> The rest of the file uses "ok". So, the addition above is consistent
> with the other entries.
>
> Perhaps a patch outside this series to convert the entire file from
> "ok" to "okay" would be acceptable to you.
OK, it would...
>
> Thanks,
> Jon
MBR, Sergei
^ permalink raw reply
* [PATCH net-next 2/2] net: phy: Add Meson GXL Internal PHY driver
From: Andrew Lunn @ 2016-11-05 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478274683-1503-3-git-send-email-narmstrong@baylibre.com>
On Fri, Nov 04, 2016 at 04:51:23PM +0100, Neil Armstrong wrote:
> Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
>
> This PHY seems to only implement some standard registers and need some
> workarounds to provide autoneg values from vendor registers.
>
> Some magic values are currently used to configure the PHY, and this a
> temporary setup until clarification about these registers names and
> registers fields are provided by Amlogic.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-11-05 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101092304.GM1041@n2100.armlinux.org.uk>
Hi,
[add Rui]
> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 1. November 2016 um
> 10:23 geschrieben:
>
>
> On Mon, Oct 31, 2016 at 08:54:33PM +0100, Stefan Wahren wrote:
> > [ 366.696043] INFO: task ext4lazyinit:70 blocked for more than 120 seconds.
> > [ 366.703046] Not tainted 4.9.0-rc1 #7
> > [ 366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> > this
> > message.
> > [ 366.715161] ext4lazyinit D c05aa6ac 0 70 2 0x00000000
>
> This looks like a very different problem - I guess one for ext4 people.
>
i investigated the issue more further. This trace wasn't representative, because
the stacktrace is different in most cases. The "endless loop" is located in
freeze_enter(). So i added some debug messages:
-------------------------------->8------------------------------------
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 1e7f5da..079c08d 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -67,17 +67,20 @@ static void freeze_enter(void)
spin_unlock_irq(&suspend_freeze_lock);
get_online_cpus();
+ pr_info("PM: calling cpuidle_resume()\n");
cpuidle_resume();
/* Push all the CPUs into the idle loop. */
+ pr_info("PM: calling wake_up_all_idle_cpus()\n");
wake_up_all_idle_cpus();
- pr_debug("PM: suspend-to-idle\n");
+ pr_info("PM: suspend-to-idle\n");
/* Make the current CPU wait so it can enter the idle loop too. */
wait_event(suspend_freeze_wait_head,
suspend_freeze_state == FREEZE_STATE_WAKE);
- pr_debug("PM: resume from suspend-to-idle\n");
+ pr_info("PM: resume from suspend-to-idle\n");
cpuidle_pause();
+ pr_info("PM: called cpuidle_pause()\n");
put_online_cpus();
spin_lock_irq(&suspend_freeze_lock);
@@ -91,6 +94,8 @@ void freeze_wake(void)
{
unsigned long flags;
+ pr_info("PM: freeze_wake()\n");
+
spin_lock_irqsave(&suspend_freeze_lock, flags);
if (suspend_freeze_state > FREEZE_STATE_NONE) {
suspend_freeze_state = FREEZE_STATE_WAKE;
-------------------------------->8------------------------------------
and repeated the test cases for freeze which shows none the representative
stacktraces:
1. cmdline contains no_console_suspend
* echo freeze > /sys/power/state
...
[ 139.371308] PM: suspend of devices complete after 1342.721 msecs
[ 139.385203] PM: late suspend of devices complete after 7.668 msecs
[ 139.399428] PM: noirq suspend of devices complete after 7.936 msecs
[ 139.406639] PM: calling cpuidle_resume()
[ 139.410619] PM: calling wake_up_all_idle_cpus()
[ 139.415339] PM: suspend-to-idle
>>> no reaction to input via Debug UART
[ 366.683570] INFO: task bash:373 blocked for more than 120 seconds.
[ 366.689814] Not tainted 4.9.0-rc1-dirty #14
[ 366.694705] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 366.702685] bash D c05aa6ec 0 373 275 0x00000000
[ 366.709227] [<c05aa6ec>] (__schedule) from [<c05aaff8>] (schedule+0x3c/0xbc)
[ 366.716495] [<c05aaff8>] (schedule) from [<c005b588>]
(suspend_devices_and_enter+0x888/0xa78)
[ 366.725228] [<c005b588>] (suspend_devices_and_enter) from [<c005bea4>]
(pm_suspend+0x72c/0x81c)
[ 366.734150] [<c005bea4>] (pm_suspend) from [<c005a008>]
(state_store+0x80/0xcc)
[ 366.741554] [<c005a008>] (state_store) from [<c02f0270>]
(kobj_attr_store+0x18/0x1c)
[ 366.749515] [<c02f0270>] (kobj_attr_store) from [<c01911e8>]
(sysfs_kf_write+0x48/0x4c)
[ 366.757735] [<c01911e8>] (sysfs_kf_write) from [<c0190308>]
(kernfs_fop_write+0xfc/0x1d0)
[ 366.766130] [<c0190308>] (kernfs_fop_write) from [<c011f578>]
(__vfs_write+0x2c/0x124)
[ 366.774255] [<c011f578>] (__vfs_write) from [<c011f724>]
(vfs_write+0xb4/0x1a4)
[ 366.781640] [<c011f724>] (vfs_write) from [<c011f8e8>] (SyS_write+0x44/0x88)
[ 366.788890] [<c011f8e8>] (SyS_write) from [<c000a2c0>]
(ret_fast_syscall+0x0/0x1c)
[ 366.796627]
[ 366.796627] Showing all locks held in the system:
[ 366.803011] 2 locks held by khungtaskd/10:
[ 366.807149] #0: [ 366.808931] (
rcu_read_lock[ 366.811784] ){......}
, at: [ 366.814813] [<c0093a40>] watchdog+0xb4/0x61c
[ 366.819128] #1: [ 366.820902] (
tasklist_lock[ 366.823876] ){.+.+..}
, at: [ 366.826765] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
[ 366.832151] 4 locks held by bash/373:
[ 366.835973] #0: [ 366.837765] (
sb_writers[ 366.840365] #4
){.+.+.+}[ 366.842987] , at:
[ 366.845079] [<c011f804>] vfs_write+0x194/0x1a4
[ 366.849551] #1: [ 366.851324] (
&of->mutex[ 366.854058] ){+.+.+.}
, at: [ 366.856944] [<c01902cc>] kernfs_fop_write+0xc0/0x1d0
[ 366.861941] #2: [ 366.863839] (
s_active[ 366.866288] #43
){.+.+.+}[ 366.868877] , at:
[ 366.870938] [<c01902d4>] kernfs_fop_write+0xc8/0x1d0
[ 366.876053] #3: [ 366.877843] (
pm_mutex[ 366.880272] ){+.+.+.}
, at: [ 366.883266] [<c005b808>] pm_suspend+0x90/0x81c
[ 366.887757]
[ 366.889268] =============================================
[ 366.889268]
2. cmdline contains no_console_suspend
* echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
* echo freeze > /sys/power/state
the same as in 1.
3. cmdline doesn't contains no_console_suspend
* echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
* echo freeze > /sys/power/state
[ 161.093187] PM: Syncing filesystems ... [ 161.734413] done.
[ 161.793242] Freezing user space processes ... (elapsed 0.008 seconds) done.
[ 161.809797] Freezing remaining freezable tasks ... (elapsed 0.004 seconds)
done.
[ 161.821953] Suspending console(s) (use no_console_suspend to debug)
>>>> no reaction to Debug UART
I expected that in all 3 cases freeze_wake() will be called. Why not?
Here my config again:
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM=y
CONFIG_CPU_IDLE is not set
^ permalink raw reply related
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-11-05 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478299359.26659.5.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016 um 23:42
> geschrieben:
>
>
> Hi Stefan,
>
> sorry, I forget the link in the previous mail.
>
> On Fri, 2016-11-04 at 20:30 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
> > > J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016
> > > um 19:44
> > > geschrieben:
> > >
> > >
> > > Hi Shawn,
> > >
> > > On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > > > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29.
> > > > > > > Oktober
> > > > > > > 2016
> > > > > > > um 01:07
> > > > > > > geschrieben:
> > > > > > >
> > > > > > >
> > > > > > > You mentioned [1] an optimization in the Freescale vendor
> > > > > > > Linux
> > > > > > > kernel
> > > > > > > [2]. I would really like to see this optimization in the
> > > > > > > mainline
> > > > > > > kernel.
> > > > > > >
> > > > > > > Did you ever tried to port this code from Freescale to
> > > > > > > mainline?
> > > > > >
> > > > > > Yes, i tried once but i was frustrated soon because of the
> > > > > > lot of
> > > > > > required
> > > > > > changes and resulting issues.
> > > > >
> > > > > I got the PIO mode working for the mxs-mmc driver. For this I
> > > > > ported
> > > > > the PIO code from the vendor kernel and removed the usage of
> > > > > the
> > > > > DMA
> > > > > engine entirely.
> > > >
> > > > Good job
> > > >
> > > > >
> > > > > Testing network bandwidth with iperf, I get about ~10Mbit/sec
> > > > > with
> > > > > PIO
> > > > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > > > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
> > > >
> > > > And how about MMC / sd card performance?
> > >
> > > I noticed poor performance with the i.MX28 MMC and/or DMA driver
> > > using
> > > the mainline kernel compared to the vendor Freescale kernel 2.6.35.
> > > I've seen that hou have added the drivers to mainline some years
> > > ago.
> > >
> > > My custom i.MX28 board has a wifi chip attached to the SSP2
> > > interface.
> > > Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
> > > kernel and <5Mbits/sec on the mainline kernel.
> >
> > there is one thing about the clock handling. I noticed that the
> > Vendor Kernel
> > round up the clock frequency and the Mainline Kernel round down the
> > clock
> > frequency [1]. So don't trust the clock ratings from DT / board code.
> > Better
> > verify the register settings or check it with an osci.
> >
> > [1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
>
> I checked the clock rate setting by reading the register 0x80014070
> (HW_SSP2_TIMING). CLOCK_DIVIDE is 0x2 and CLOCK_RATE is 0x0. As SSP CLK
> is 96MHz this makes a clock rate of 48MHz.
>
> There was a discussion on the mailing list [1] about that tasklets
> might be slow.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February
> /043395.html
if i unterstand it right the tasklet is not the problem, but the design of the
MXS DMA driver. Please refer to the chapter "General Design Notes" to the
documentation of the DMA provider [2].
I think the MXS DMA driver is affected. Maybe you should ask Vinod Koul about
this.
[2] - https://www.kernel.org/doc/Documentation/dmaengine/provider.txt
>
> J?rg
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Zhang Rui @ 2016-11-05 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <322177156.158733.9867e3e7-5710-4844-a098-6f44bd852a6d.open-xchange@email.1und1.de>
On Sat, 2016-11-05 at 12:07 +0100, Stefan Wahren wrote:
> Hi,
>
> [add Rui]
>
> >
> > Russell King - ARM Linux <linux@armlinux.org.uk> hat am 1. November
> > 2016 um
> > 10:23 geschrieben:
> >
> >
> > On Mon, Oct 31, 2016 at 08:54:33PM +0100, Stefan Wahren wrote:
> > >
> > > [??366.696043] INFO: task ext4lazyinit:70 blocked for more than
> > > 120 seconds.
> > > [??366.703046]???????Not tainted 4.9.0-rc1 #7
> > > [??366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > > disables
> > > this
> > > message.
> > > [??366.715161] ext4lazyinit????D c05aa6ac?????0????70??????2
> > > 0x00000000
> > This looks like a very different problem - I guess one for ext4
> > people.
> >
> i investigated the issue more further. This trace wasn't
> representative, because
> the stacktrace is different in most cases. The "endless loop" is
> located in
> freeze_enter(). So i added some debug messages:
>
is this a regression?
> -------------------------------->8-----------------------------------
> -
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 1e7f5da..079c08d 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -67,17 +67,20 @@ static void freeze_enter(void)
> ? spin_unlock_irq(&suspend_freeze_lock);
> ?
> ? get_online_cpus();
> + pr_info("PM: calling cpuidle_resume()\n");
> ? cpuidle_resume();
> ?
> ? /* Push all the CPUs into the idle loop. */
> + pr_info("PM: calling wake_up_all_idle_cpus()\n");
> ? wake_up_all_idle_cpus();
> - pr_debug("PM: suspend-to-idle\n");
> + pr_info("PM: suspend-to-idle\n");
> ? /* Make the current CPU wait so it can enter the idle loop
> too. */
> ? wait_event(suspend_freeze_wait_head,
> ? ???suspend_freeze_state == FREEZE_STATE_WAKE);
> - pr_debug("PM: resume from suspend-to-idle\n");
> + pr_info("PM: resume from suspend-to-idle\n");
> ?
> ? cpuidle_pause();
> + pr_info("PM: called cpuidle_pause()\n");
> ? put_online_cpus();
> ?
> ? spin_lock_irq(&suspend_freeze_lock);
> @@ -91,6 +94,8 @@ void freeze_wake(void)
> ?{
> ? unsigned long flags;
> ?
> + pr_info("PM: freeze_wake()\n");
> +
> ? spin_lock_irqsave(&suspend_freeze_lock, flags);
> ? if (suspend_freeze_state > FREEZE_STATE_NONE) {
> ? suspend_freeze_state = FREEZE_STATE_WAKE;
>
> -------------------------------->8-----------------------------------
> -
>
> and repeated the test cases for freeze which shows none the
> representative
> stacktraces:
>
> 1. cmdline contains no_console_suspend
>
> * echo freeze > /sys/power/state
>
> ...
> [??139.371308] PM: suspend of devices complete after 1342.721 msecs
> [??139.385203] PM: late suspend of devices complete after 7.668 msecs
> [??139.399428] PM: noirq suspend of devices complete after 7.936
> msecs
> [??139.406639] PM: calling cpuidle_resume()
> [??139.410619] PM: calling wake_up_all_idle_cpus()
> [??139.415339] PM: suspend-to-idle
>
> >
> > >
> > > >
> > > > no reaction to input via Debug UART
> [??366.683570] INFO: task bash:373 blocked for more than 120 seconds.
> [??366.689814]???????Not tainted 4.9.0-rc1-dirty #14
> [??366.694705] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this
> message.
> [??366.702685] bash????????????D c05aa6ec?????0???373????275
> 0x00000000
> [??366.709227] [<c05aa6ec>] (__schedule) from [<c05aaff8>]
> (schedule+0x3c/0xbc)
> [??366.716495] [<c05aaff8>] (schedule) from [<c005b588>]
> (suspend_devices_and_enter+0x888/0xa78)
> [??366.725228] [<c005b588>] (suspend_devices_and_enter) from
> [<c005bea4>]
> (pm_suspend+0x72c/0x81c)
> [??366.734150] [<c005bea4>] (pm_suspend) from [<c005a008>]
> (state_store+0x80/0xcc)
> [??366.741554] [<c005a008>] (state_store) from [<c02f0270>]
> (kobj_attr_store+0x18/0x1c)
> [??366.749515] [<c02f0270>] (kobj_attr_store) from [<c01911e8>]
> (sysfs_kf_write+0x48/0x4c)
> [??366.757735] [<c01911e8>] (sysfs_kf_write) from [<c0190308>]
> (kernfs_fop_write+0xfc/0x1d0)
> [??366.766130] [<c0190308>] (kernfs_fop_write) from [<c011f578>]
> (__vfs_write+0x2c/0x124)
> [??366.774255] [<c011f578>] (__vfs_write) from [<c011f724>]
> (vfs_write+0xb4/0x1a4)
> [??366.781640] [<c011f724>] (vfs_write) from [<c011f8e8>]
> (SyS_write+0x44/0x88)
> [??366.788890] [<c011f8e8>] (SyS_write) from [<c000a2c0>]
> (ret_fast_syscall+0x0/0x1c)
> [??366.796627]
> [??366.796627] Showing all locks held in the system:
> [??366.803011] 2 locks held by khungtaskd/10:
> [??366.807149]??#0: [??366.808931]??(
> rcu_read_lock[??366.811784] ){......}
> , at: [??366.814813] [<c0093a40>] watchdog+0xb4/0x61c
> [??366.819128]??#1: [??366.820902]??(
> tasklist_lock[??366.823876] ){.+.+..}
> , at: [??366.826765] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
> [??366.832151] 4 locks held by bash/373:
> [??366.835973]??#0: [??366.837765]??(
> sb_writers[??366.840365] #4
> ){.+.+.+}[??366.842987] , at:
> [??366.845079] [<c011f804>] vfs_write+0x194/0x1a4
> [??366.849551]??#1: [??366.851324]??(
> &of->mutex[??366.854058] ){+.+.+.}
> , at: [??366.856944] [<c01902cc>] kernfs_fop_write+0xc0/0x1d0
> [??366.861941]??#2: [??366.863839]??(
> s_active[??366.866288] #43
> ){.+.+.+}[??366.868877] , at:
> [??366.870938] [<c01902d4>] kernfs_fop_write+0xc8/0x1d0
> [??366.876053]??#3: [??366.877843]??(
> pm_mutex[??366.880272] ){+.+.+.}
> , at: [??366.883266] [<c005b808>] pm_suspend+0x90/0x81c
> [??366.887757]
> [??366.889268] =============================================
> [??366.889268]
>
> 2. cmdline contains no_console_suspend
>
> * echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
> * echo freeze > /sys/power/state
>
> the same as in 1.
>
> 3. cmdline doesn't contains no_console_suspend
>
> * echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
> * echo freeze > /sys/power/state
>
> [??161.093187] PM: Syncing filesystems ... [??161.734413] done.
> [??161.793242] Freezing user space processes ... (elapsed 0.008
> seconds) done.
> [??161.809797] Freezing remaining freezable tasks ... (elapsed 0.004
> seconds)
> done.
> [??161.821953] Suspending console(s) (use no_console_suspend to
> debug)
>
> >?
> > > > > no reaction to Debug UART
Then the system does not have any response? or the system freezes and
wakes up as expected?
> I expected that in all 3 cases freeze_wake() will be called. Why not?
>
> Here my config again:
>
> CONFIG_PM_SLEEP=y
> CONFIG_SUSPEND=y
> CONFIG_SUSPEND_FREEZER=y
> CONFIG_PM=y
> CONFIG_CPU_IDLE is not set
hmmm, why not have CONFIG_CPU_IDLE set?
thanks,
rui
^ permalink raw reply
* [PATCH v8 0/3] ARM, arm64: renesas: Enable UHS-I SDR-104
From: Wolfram Sang @ 2016-11-05 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478185645-25556-1-git-send-email-horms+renesas@verge.net.au>
> To aid review the following git branches are provided:
> * This patchset:
> https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/sdr104-integration-v8
> * This patch-set and above dependency
> https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/sdr104-v8
driver-v8 is there, but those two are not. Forgot to push out? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161105/84af31ec/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
From: Shawn Guo @ 2016-11-05 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478044305-5666-1-git-send-email-stillcompiling@gmail.com>
On Tue, Nov 01, 2016 at 04:51:45PM -0700, Joshua Clayton wrote:
> imx-weim should always set address-cells to 2,
> and size_cells to 1.
> On imx6, fsl,weim-cs-gpr will always be &gpr
>
> Set these common parameters in the dtsi file,
> rather than in a downstream dts.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Applied, thanks.
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-11-05 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478345972.2206.15.camel@intel.com>
Hi Rui,
> Zhang Rui <rui.zhang@intel.com> hat am 5. November 2016 um 12:39 geschrieben:
>
>
> On Sat, 2016-11-05 at 12:07 +0100, Stefan Wahren wrote:
> > Hi,
> >
> > [add Rui]
> >
> > >
> > > Russell King - ARM Linux <linux@armlinux.org.uk> hat am 1. November
> > > 2016 um
> > > 10:23 geschrieben:
> > >
> > >
> > > On Mon, Oct 31, 2016 at 08:54:33PM +0100, Stefan Wahren wrote:
> > > >
> > > > [??366.696043] INFO: task ext4lazyinit:70 blocked for more than
> > > > 120 seconds.
> > > > [??366.703046]???????Not tainted 4.9.0-rc1 #7
> > > > [??366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > > > disables
> > > > this
> > > > message.
> > > > [??366.715161] ext4lazyinit????D c05aa6ac?????0????70??????2
> > > > 0x00000000
> > > This looks like a very different problem - I guess one for ext4
> > > people.
> > >
> > i investigated the issue more further. This trace wasn't
> > representative, because
> > the stacktrace is different in most cases. The "endless loop" is
> > located in
> > freeze_enter(). So i added some debug messages:
> >
> is this a regression?
i've never seen this working on MXS platform, but maybe i hit a corner case. The
oldest kernel that i tested was 3.18 and this issue was reproducible. Should i
test an older version?
> >
> > and repeated the test cases for freeze which shows none the
> > representative
> > stacktraces:
> >
> > 1. cmdline contains no_console_suspend
> >
> > * echo freeze > /sys/power/state
> >
> > ...
> > [??139.371308] PM: suspend of devices complete after 1342.721 msecs
> > [??139.385203] PM: late suspend of devices complete after 7.668 msecs
> > [??139.399428] PM: noirq suspend of devices complete after 7.936
> > msecs
> > [??139.406639] PM: calling cpuidle_resume()
> > [??139.410619] PM: calling wake_up_all_idle_cpus()
> > [??139.415339] PM: suspend-to-idle
> >
> > >
> > > >
> > > > >
> > > > > no reaction to input via Debug UART
> > [??366.683570] INFO: task bash:373 blocked for more than 120 seconds.
> > [??366.689814]???????Not tainted 4.9.0-rc1-dirty #14
> > [??366.694705] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > disables this
> > message.
> > [??366.702685] bash????????????D c05aa6ec?????0???373????275
> > 0x00000000
> > [??366.709227] [<c05aa6ec>] (__schedule) from [<c05aaff8>]
> > (schedule+0x3c/0xbc)
> > [??366.716495] [<c05aaff8>] (schedule) from [<c005b588>]
> > (suspend_devices_and_enter+0x888/0xa78)
> > [??366.725228] [<c005b588>] (suspend_devices_and_enter) from
> > [<c005bea4>]
> > (pm_suspend+0x72c/0x81c)
> > [??366.734150] [<c005bea4>] (pm_suspend) from [<c005a008>]
> > (state_store+0x80/0xcc)
> > [??366.741554] [<c005a008>] (state_store) from [<c02f0270>]
> > (kobj_attr_store+0x18/0x1c)
> > [??366.749515] [<c02f0270>] (kobj_attr_store) from [<c01911e8>]
> > (sysfs_kf_write+0x48/0x4c)
> > [??366.757735] [<c01911e8>] (sysfs_kf_write) from [<c0190308>]
> > (kernfs_fop_write+0xfc/0x1d0)
> > [??366.766130] [<c0190308>] (kernfs_fop_write) from [<c011f578>]
> > (__vfs_write+0x2c/0x124)
> > [??366.774255] [<c011f578>] (__vfs_write) from [<c011f724>]
> > (vfs_write+0xb4/0x1a4)
> > [??366.781640] [<c011f724>] (vfs_write) from [<c011f8e8>]
> > (SyS_write+0x44/0x88)
> > [??366.788890] [<c011f8e8>] (SyS_write) from [<c000a2c0>]
> > (ret_fast_syscall+0x0/0x1c)
> > [??366.796627]
> > [??366.796627] Showing all locks held in the system:
> > [??366.803011] 2 locks held by khungtaskd/10:
> > [??366.807149]??#0: [??366.808931]??(
> > rcu_read_lock[??366.811784] ){......}
> > , at: [??366.814813] [<c0093a40>] watchdog+0xb4/0x61c
> > [??366.819128]??#1: [??366.820902]??(
> > tasklist_lock[??366.823876] ){.+.+..}
> > , at: [??366.826765] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
> > [??366.832151] 4 locks held by bash/373:
> > [??366.835973]??#0: [??366.837765]??(
> > sb_writers[??366.840365] #4
> > ){.+.+.+}[??366.842987] , at:
> > [??366.845079] [<c011f804>] vfs_write+0x194/0x1a4
> > [??366.849551]??#1: [??366.851324]??(
> > &of->mutex[??366.854058] ){+.+.+.}
> > , at: [??366.856944] [<c01902cc>] kernfs_fop_write+0xc0/0x1d0
> > [??366.861941]??#2: [??366.863839]??(
> > s_active[??366.866288] #43
> > ){.+.+.+}[??366.868877] , at:
> > [??366.870938] [<c01902d4>] kernfs_fop_write+0xc8/0x1d0
> > [??366.876053]??#3: [??366.877843]??(
> > pm_mutex[??366.880272] ){+.+.+.}
> > , at: [??366.883266] [<c005b808>] pm_suspend+0x90/0x81c
> > [??366.887757]
> > [??366.889268] =============================================
> > [??366.889268]
> >
> > 2. cmdline contains no_console_suspend
> >
> > * echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
> > * echo freeze > /sys/power/state
> >
> > the same as in 1.
> >
> > 3. cmdline doesn't contains no_console_suspend
> >
> > * echo enabled > /sys/class/tty/ttyAMA0/power/wakeup
> > * echo freeze > /sys/power/state
> >
> > [??161.093187] PM: Syncing filesystems ... [??161.734413] done.
> > [??161.793242] Freezing user space processes ... (elapsed 0.008
> > seconds) done.
> > [??161.809797] Freezing remaining freezable tasks ... (elapsed 0.004
> > seconds)
> > done.
> > [??161.821953] Suspending console(s) (use no_console_suspend to
> > debug)
> >
> > >?
> > > > > > no reaction to Debug UART
>
> Then the system does not have any response? or the system freezes and
> wakes up as expected?
The system doesn't react to any input from Debug UART and after 2 minutes i got
the following stacktrace about hung task. But i didn't get any change to come
back to the console. Interestingly basic PM debugging tests doesn't show this
issue. Also "echo mem > /sys/power/state" doesn't cause this issue.
>
> > I expected that in all 3 cases freeze_wake() will be called. Why not?
> >
> > Here my config again:
> >
> > CONFIG_PM_SLEEP=y
> > CONFIG_SUSPEND=y
> > CONFIG_SUSPEND_FREEZER=y
> > CONFIG_PM=y
> > CONFIG_CPU_IDLE is not set
>
> hmmm, why not have CONFIG_CPU_IDLE set?
I'm using mxs_defconfig which doesn't select the ARM CPU idle. Is this
necessary?
>
> thanks,
> rui
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.9
From: Fabio Estevam @ 2016-11-05 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5D9uBBwWV8UJOLj-2iwWO6sReB5BAtzdi1q6OqbtvcSOQ@mail.gmail.com>
Hi Olof,
On Mon, Oct 31, 2016 at 9:29 PM, Fabio Estevam <festevam@gmail.com> wrote:
> I think this will be fixed with this pcie-designware patch:
> http://www.spinics.net/lists/linux-pci/msg55244.html
Bjorn sent this fix to Linus, so we should be fine now.
>
>> Wandboard, has a peculiar MMC error. First I thought it was just the
>> card going bad, but now I'm not so sure since multi_v7 boots just fine
>> on the same hardware:
>
> Yes, I have been noticing this mmc error reported in your autobooter
> and I also thought it was some kind of a bad SD card.
>
> This particular error I have never been able to reproduce. Also
> checked kernelci and do not see this mmc error there.
>
> Interesting that it happens only with imx_v6_v7_defconfig and not with
> multi_v7_defconfig.
Today wandboard does not show the mmc error with imx_v6_v7_defconfig:
http://arm-soc.lixom.net/bootlogs/mainline/v4.9-rc3-376-gfb415f2/wandboard-arm-imx_v6_v7_defconfig.html
Looks like the mmc error come and go?
^ permalink raw reply
* [PATCH v7 0/2] Introducing Exynos ChipId driver
From: Pankaj Dubey @ 2016-11-05 12:03 UTC (permalink / raw)
To: linux-arm-kernel
Once again I am attempting this quite old patch series to introduce
Exynos Chipid driver.
Each Exynos SoC has ChipID block which can give information about SoC's
product Id and revision number.
This patch series introduces Exynos Chipid SoC driver. At the same time
it reduces dependency of mach-exynos files from plat-samsung, by removing
soc_is_exynosMMMM and samsung_rev API. Instead of it now we can use
soc_device_match API proposed by Arnd and getting discussed in thread [1].
Until now we are using static mapping of Exynos Chipid and using this static
mapping to know about SoC name and revision via soc_is_exynosMMMM macro. This
is quite cumbersome and every time new ARMv7 based Exynos SoC supports lands in
mainline a bunch of such new macros needs to be added. Quite long back during
support of Exynos5260 it has been discussed to solve this problem.
To solve this issue this patchset replaces use of soc_is_exynosMMMM by either
of_machine_is_compatible or soc_device_match depending upon usecase.
This patchset depends on [2], and I have prepared it on top of my other patchset [3]
(under-review) which introduces SCU device node for Exynos
I have tested this patch series on Exynos4210 based Origen board for normal SMP
boot.
[1]: https://patchwork.kernel.org/patch/9361389/
[2]: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1261739.html
[3]: http://www.spinics.net/lists/arm-kernel/msg540498.html
Revision 6 and it's discussion can be found here:
- https://lkml.org/lkml/2016/5/25/101
Revision 5 and it's discussion can be found here:
- http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310046.html
Revision 4 and it's discussion can be found here:
- https://lkml.org/lkml/2014/12/3/115
Chances since v6:
- Removed platform driver from chipid, instead use early_init to register soc_device
- Removed export functions from exynos chipid driver
- Replace soc_is_exynosMMMM via either of_machine_is_compatible or soc_device_match in
files in arm/mach-exynos folder
- This patchset depends on the following patch series by Geert Uytterhoeven. This series
includes patch which introduces soc_device_match.
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1261739.html
- Rebased on latest krzk/for-next branch and retested.
Change since v5:
- Addressed Rob's review comments.
- Rebased on latest krzk/for-next branch and retested.
Changes since v4:
- Removed custom sysfs entries as they were not providing any new information
as pointed out by Arnd.
- Removed functions exporting product_id and revision, instead we will export
exynos_chipid_info structure. It will be helpfull when we need to provide more
fields of chipid outside of chipid, as commented by Yadwinder
- Converted all funcions as __init.
Change since v3:
- This patch set contains 5/6 and 6/6 patch from v3 series.
- Made EXYNOS_CHIPID config option non-user selectable,
as suggested by Tomasz Figa.
- Made uniform macro for EXYNOS4/5_SOC_MASK as EXYNOS_SOC_MASK as
suggested by Tomasz Figa.
- Made local variables static in chipid driver.
- Added existing SoC's product id's.
- Added platform driver support.
Changes since v2:
- Reorganized patches as suggested by Tomasz Figa.
- Addressed review comments of Tomasz Figa in i2c-s3c2410.c file.
Pankaj Dubey (2):
soc: samsung: add exynos chipid driver support
ARM: EXYNOS: refactoring of mach-exynos to enable chipid driver
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-exynos/common.h | 92 -----------------
arch/arm/mach-exynos/exynos.c | 31 ------
arch/arm/mach-exynos/firmware.c | 10 +-
arch/arm/mach-exynos/include/mach/map.h | 21 ----
arch/arm/mach-exynos/platsmp.c | 22 ++--
arch/arm/mach-exynos/pm.c | 41 +++++---
arch/arm/plat-samsung/cpu.c | 14 ---
arch/arm/plat-samsung/include/plat/cpu.h | 2 -
arch/arm/plat-samsung/include/plat/map-s5p.h | 2 -
drivers/soc/samsung/Kconfig | 5 +
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-chipid.c | 148 +++++++++++++++++++++++++++
13 files changed, 201 insertions(+), 189 deletions(-)
delete mode 100644 arch/arm/mach-exynos/include/mach/map.h
create mode 100644 drivers/soc/samsung/exynos-chipid.c
--
2.7.4
^ permalink raw reply
* [PATCH v7 1/2] soc: samsung: add exynos chipid driver support
From: Pankaj Dubey @ 2016-11-05 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478347427-28409-1-git-send-email-pankaj.dubey@samsung.com>
Exynos SoCs have Chipid, for identification of product IDs
and SoC revisions. This patch intends to provide initialization
code for all these functionalities, at the same time it provides some
sysfs entries for accessing these information to user-space.
This driver uses existing binding for exynos-chipid.
CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
drivers/soc/samsung/Kconfig | 5 ++
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-chipid.c | 148 ++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 drivers/soc/samsung/exynos-chipid.c
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2455339..f9ab858 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -14,4 +14,9 @@ config EXYNOS_PM_DOMAINS
bool "Exynos PM domains" if COMPILE_TEST
depends on PM_GENERIC_DOMAINS || COMPILE_TEST
+config EXYNOS_CHIPID
+ bool "Exynos Chipid controller driver" if COMPILE_TEST
+ depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
+ select SOC_BUS
+
endif
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 3619f2e..2a8a85e 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
exynos5250-pmu.o exynos5420-pmu.o
obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
+obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
new file mode 100644
index 0000000..9761e54
--- /dev/null
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS - CHIP ID support
+ * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS4210_SOC_ID 0x43210000
+#define EXYNOS4212_SOC_ID 0x43220000
+#define EXYNOS4412_SOC_ID 0xE4412000
+#define EXYNOS4415_SOC_ID 0xE4415000
+#define EXYNOS5250_SOC_ID 0x43520000
+#define EXYNOS5260_SOC_ID 0xE5260000
+#define EXYNOS5410_SOC_ID 0xE5410000
+#define EXYNOS5420_SOC_ID 0xE5420000
+#define EXYNOS5440_SOC_ID 0xE5440000
+#define EXYNOS5800_SOC_ID 0xE5422000
+
+#define EXYNOS_SOC_MASK 0xFFFFF000
+
+#define EXYNOS4210_REV_0 0x0
+#define EXYNOS4210_REV_1_0 0x10
+#define EXYNOS4210_REV_1_1 0x11
+
+#define EXYNOS_SUBREV_MASK (0xF << 4)
+#define EXYNOS_MAINREV_MASK (0xF << 0)
+#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
+
+
+static const char * __init product_id_to_soc_id(unsigned int product_id)
+{
+ const char *soc_name;
+ unsigned int soc_id = product_id & EXYNOS_SOC_MASK;
+
+ switch (soc_id) {
+ case EXYNOS3250_SOC_ID:
+ soc_name = "EXYNOS3250";
+ break;
+ case EXYNOS4210_SOC_ID:
+ soc_name = "EXYNOS4210";
+ break;
+ case EXYNOS4212_SOC_ID:
+ soc_name = "EXYNOS4212";
+ break;
+ case EXYNOS4412_SOC_ID:
+ soc_name = "EXYNOS4412";
+ break;
+ case EXYNOS4415_SOC_ID:
+ soc_name = "EXYNOS4415";
+ break;
+ case EXYNOS5250_SOC_ID:
+ soc_name = "EXYNOS5250";
+ break;
+ case EXYNOS5260_SOC_ID:
+ soc_name = "EXYNOS5260";
+ break;
+ case EXYNOS5420_SOC_ID:
+ soc_name = "EXYNOS5420";
+ break;
+ case EXYNOS5440_SOC_ID:
+ soc_name = "EXYNOS5440";
+ break;
+ case EXYNOS5800_SOC_ID:
+ soc_name = "EXYNOS5800";
+ break;
+ default:
+ soc_name = "UNKNOWN";
+ }
+ return soc_name;
+}
+
+static const struct of_device_id of_exynos_chipid_ids[] = {
+ {
+ .compatible = "samsung,exynos4210-chipid",
+ },
+ {},
+};
+
+/**
+ * exynos_chipid_early_init: Early chipid initialization
+ */
+int __init exynos_chipid_early_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
+ struct device_node *root;
+ struct device_node *np;
+ void __iomem *exynos_chipid_base;
+ const struct of_device_id *match;
+ u32 product_id;
+ u32 revision;
+
+ np = of_find_matching_node_and_match(NULL,
+ of_exynos_chipid_ids, &match);
+ if (!np)
+ return -ENODEV;
+
+ exynos_chipid_base = of_iomap(np, 0);
+
+ if (!exynos_chipid_base)
+ return PTR_ERR(exynos_chipid_base);
+
+ product_id = __raw_readl(exynos_chipid_base);
+ revision = product_id & EXYNOS_REV_MASK;
+ iounmap(exynos_chipid_base);
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENODEV;
+
+ soc_dev_attr->family = "Samsung Exynos";
+
+ root = of_find_node_by_path("/");
+ of_property_read_string(root, "model", &soc_dev_attr->machine);
+ of_node_put(root);
+
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x", revision);
+ soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
+
+
+ pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
+ product_id_to_soc_id(product_id), revision);
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->revision);
+ kfree_const(soc_dev_attr->soc_id);
+ kfree(soc_dev_attr);
+ return PTR_ERR(soc_dev);
+ }
+
+ return 0;
+}
+early_initcall(exynos_chipid_early_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/2] ARM: EXYNOS: refactoring of mach-exynos to enable chipid driver
From: Pankaj Dubey @ 2016-11-05 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478347427-28409-1-git-send-email-pankaj.dubey@samsung.com>
This patch enables chipid driver for ARCH_EXYNOS and refactors
machine code for using chipid driver for identification of
SoC ID and SoC rev.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-exynos/common.h | 92 ----------------------------
arch/arm/mach-exynos/exynos.c | 31 ----------
arch/arm/mach-exynos/firmware.c | 10 +--
arch/arm/mach-exynos/include/mach/map.h | 21 -------
arch/arm/mach-exynos/platsmp.c | 22 ++++---
arch/arm/mach-exynos/pm.c | 41 ++++++++-----
arch/arm/plat-samsung/cpu.c | 14 -----
arch/arm/plat-samsung/include/plat/cpu.h | 2 -
arch/arm/plat-samsung/include/plat/map-s5p.h | 2 -
10 files changed, 47 insertions(+), 189 deletions(-)
delete mode 100644 arch/arm/mach-exynos/include/mach/map.h
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index b085855..a76c679 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_AMBA
select ARM_GIC
select COMMON_CLK_SAMSUNG
+ select EXYNOS_CHIPID
select EXYNOS_THERMAL
select EXYNOS_PMU
select EXYNOS_SROM
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index d19064b..9d76cf8 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -14,97 +14,6 @@
#include <linux/platform_data/cpuidle-exynos.h>
-#define EXYNOS3250_SOC_ID 0xE3472000
-#define EXYNOS3_SOC_MASK 0xFFFFF000
-
-#define EXYNOS4210_CPU_ID 0x43210000
-#define EXYNOS4212_CPU_ID 0x43220000
-#define EXYNOS4412_CPU_ID 0xE4412200
-#define EXYNOS4_CPU_MASK 0xFFFE0000
-
-#define EXYNOS5250_SOC_ID 0x43520000
-#define EXYNOS5410_SOC_ID 0xE5410000
-#define EXYNOS5420_SOC_ID 0xE5420000
-#define EXYNOS5440_SOC_ID 0xE5440000
-#define EXYNOS5800_SOC_ID 0xE5422000
-#define EXYNOS5_SOC_MASK 0xFFFFF000
-
-extern unsigned long samsung_cpu_id;
-
-#define IS_SAMSUNG_CPU(name, id, mask) \
-static inline int is_samsung_##name(void) \
-{ \
- return ((samsung_cpu_id & mask) == (id & mask)); \
-}
-
-IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
-IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
-
-#if defined(CONFIG_SOC_EXYNOS3250)
-# define soc_is_exynos3250() is_samsung_exynos3250()
-#else
-# define soc_is_exynos3250() 0
-#endif
-
-#if defined(CONFIG_CPU_EXYNOS4210)
-# define soc_is_exynos4210() is_samsung_exynos4210()
-#else
-# define soc_is_exynos4210() 0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS4212)
-# define soc_is_exynos4212() is_samsung_exynos4212()
-#else
-# define soc_is_exynos4212() 0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS4412)
-# define soc_is_exynos4412() is_samsung_exynos4412()
-#else
-# define soc_is_exynos4412() 0
-#endif
-
-#define EXYNOS4210_REV_0 (0x0)
-#define EXYNOS4210_REV_1_0 (0x10)
-#define EXYNOS4210_REV_1_1 (0x11)
-
-#if defined(CONFIG_SOC_EXYNOS5250)
-# define soc_is_exynos5250() is_samsung_exynos5250()
-#else
-# define soc_is_exynos5250() 0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS5410)
-# define soc_is_exynos5410() is_samsung_exynos5410()
-#else
-# define soc_is_exynos5410() 0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS5420)
-# define soc_is_exynos5420() is_samsung_exynos5420()
-#else
-# define soc_is_exynos5420() 0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS5440)
-# define soc_is_exynos5440() is_samsung_exynos5440()
-#else
-# define soc_is_exynos5440() 0
-#endif
-
-#if defined(CONFIG_SOC_EXYNOS5800)
-# define soc_is_exynos5800() is_samsung_exynos5800()
-#else
-# define soc_is_exynos5800() 0
-#endif
-
extern u32 cp15_save_diag;
extern u32 cp15_save_power;
@@ -161,7 +70,6 @@ extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
extern void exynos_set_delayed_reset_assertion(bool enable);
-extern unsigned int samsung_rev(void);
extern void exynos_core_restart(u32 core_id);
extern int exynos_set_boot_addr(u32 core_id, unsigned long boot_addr);
extern int exynos_get_boot_addr(u32 core_id, unsigned long *boot_addr);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index fa08ef9..942131e 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -23,9 +23,6 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
-#include <mach/map.h>
-#include <plat/cpu.h>
-
#include "common.h"
static struct platform_device exynos_cpuidle = {
@@ -67,37 +64,9 @@ static void __init exynos_init_late(void)
exynos_pm_init();
}
-static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
- int depth, void *data)
-{
- struct map_desc iodesc;
- const __be32 *reg;
- int len;
-
- if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
- !of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
- return 0;
-
- reg = of_get_flat_dt_prop(node, "reg", &len);
- if (reg == NULL || len != (sizeof(unsigned long) * 2))
- return 0;
-
- iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
- iodesc.length = be32_to_cpu(reg[1]) - 1;
- iodesc.virtual = (unsigned long)S5P_VA_CHIPID;
- iodesc.type = MT_DEVICE;
- iotable_init(&iodesc, 1);
- return 1;
-}
-
static void __init exynos_init_io(void)
{
debug_ll_io_init();
-
- of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
-
- /* detect cpu id and rev. */
- s5p_init_cpu(S5P_VA_CHIPID);
}
/*
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index fd6da54..a9f8504e 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -44,7 +44,7 @@ static int exynos_do_idle(unsigned long mode)
writel_relaxed(virt_to_phys(exynos_cpu_resume_ns),
sysram_ns_base_addr + 0x24);
writel_relaxed(EXYNOS_AFTR_MAGIC, sysram_ns_base_addr + 0x20);
- if (soc_is_exynos3250()) {
+ if (of_machine_is_compatible("samsung,exynos3250")) {
flush_cache_all();
exynos_smc(SMC_CMD_SAVE, OP_TYPE_CORE,
SMC_POWERSTATE_IDLE, 0);
@@ -65,7 +65,7 @@ static int exynos_cpu_boot(int cpu)
* Exynos3250 doesn't need to send smc command for secondary CPU boot
* because Exynos3250 removes WFE in secure mode.
*/
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
return 0;
/*
@@ -73,7 +73,7 @@ static int exynos_cpu_boot(int cpu)
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
- if (soc_is_exynos4212())
+ if (of_machine_is_compatible("samsung,exynos4212"))
cpu = 0;
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
@@ -94,7 +94,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
* additional offset for every CPU, with Exynos4412 being the only
* exception.
*/
- if (soc_is_exynos4412())
+ if (of_machine_is_compatible("samsung,exynos4412"))
boot_reg += 4 * cpu;
writel_relaxed(boot_addr, boot_reg);
@@ -110,7 +110,7 @@ static int exynos_get_cpu_boot_addr(int cpu, unsigned long *boot_addr)
boot_reg = sysram_ns_base_addr + 0x1c;
- if (soc_is_exynos4412())
+ if (of_machine_is_compatible("samsung,exynos4412"))
boot_reg += 4 * cpu;
*boot_addr = readl_relaxed(boot_reg);
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
deleted file mode 100644
index 0eef407..0000000
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- *
- * EXYNOS - Memory map definitions
- *
- * 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.
-*/
-
-#ifndef __ASM_ARCH_MAP_H
-#define __ASM_ARCH_MAP_H __FILE__
-
-#include <plat/map-base.h>
-
-#include <plat/map-s5p.h>
-
-#define EXYNOS_PA_CHIPID 0x10000000
-
-#endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 553d0d9..884e885 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -19,6 +19,7 @@
#include <linux/smp.h>
#include <linux/io.h>
#include <linux/of_address.h>
+#include <linux/sys_soc.h>
#include <linux/soc/samsung/exynos-regs-pmu.h>
#include <asm/cacheflush.h>
@@ -27,8 +28,6 @@
#include <asm/smp_scu.h>
#include <asm/firmware.h>
-#include <mach/map.h>
-
#include "common.h"
extern void exynos4_secondary_startup(void);
@@ -93,7 +92,8 @@ void exynos_cpu_power_down(int cpu)
{
u32 core_conf;
- if (cpu == 0 && (soc_is_exynos5420() || soc_is_exynos5800())) {
+ if (cpu == 0 && (of_machine_is_compatible("samsung,exynos5420") ||
+ of_machine_is_compatible("samsung,exynos5800"))) {
/*
* Bypass power down for CPU0 during suspend. Check for
* the SYS_PWR_REG value to decide if we are suspending
@@ -120,7 +120,7 @@ void exynos_cpu_power_up(int cpu)
{
u32 core_conf = S5P_CORE_LOCAL_PWR_EN;
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
core_conf |= S5P_CORE_AUTOWAKEUP_EN;
pmu_raw_writel(core_conf,
@@ -168,9 +168,14 @@ int exynos_cluster_power_state(int cluster)
S5P_CORE_LOCAL_PWR_EN);
}
+static struct soc_device_attribute exynos4210_rev11[] = {
+ { .soc_id = "EXYNOS4210", .revision = "11", },
+ { },
+};
+
static void __iomem *cpu_boot_reg_base(void)
{
- if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
+ if (soc_device_match(exynos4210_rev11))
return pmu_base_addr + S5P_INFORM5;
return sysram_base_addr;
}
@@ -182,9 +187,10 @@ static inline void __iomem *cpu_boot_reg(int cpu)
boot_reg = cpu_boot_reg_base();
if (!boot_reg)
return IOMEM_ERR_PTR(-ENODEV);
- if (soc_is_exynos4412())
+ if (of_machine_is_compatible("samsung,exynos4412"))
boot_reg += 4*cpu;
- else if (soc_is_exynos5420() || soc_is_exynos5800())
+ else if (of_machine_is_compatible("samsung,exynos5420") ||
+ of_machine_is_compatible("samsung,exynos5800"))
boot_reg += 4;
return boot_reg;
}
@@ -356,7 +362,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
call_firmware_op(cpu_boot, core_id);
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
dsb_sev();
else
arch_send_wakeup_ipi_mask(cpumask_of(cpu));
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 60e6827..430b3e2 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -19,6 +19,7 @@
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/sys_soc.h>
#include <linux/soc/samsung/exynos-regs-pmu.h>
#include <linux/soc/samsung/exynos-pmu.h>
@@ -29,20 +30,30 @@
#include "common.h"
+static struct soc_device_attribute exynos4210_rev11[] = {
+ { .soc_id = "EXYNOS4210", .revision = "11", },
+ { },
+};
+
+static struct soc_device_attribute exynos4210_rev10[] = {
+ { .soc_id = "EXYNOS4210", .revision = "10", },
+ { },
+};
+
static inline void __iomem *exynos_boot_vector_addr(void)
{
- if (samsung_rev() == EXYNOS4210_REV_1_1)
+ if (soc_device_match(exynos4210_rev11))
return pmu_base_addr + S5P_INFORM7;
- else if (samsung_rev() == EXYNOS4210_REV_1_0)
+ else if (soc_device_match(exynos4210_rev10))
return sysram_base_addr + 0x24;
return pmu_base_addr + S5P_INFORM0;
}
static inline void __iomem *exynos_boot_vector_flag(void)
{
- if (samsung_rev() == EXYNOS4210_REV_1_1)
+ if (soc_device_match(exynos4210_rev11))
return pmu_base_addr + S5P_INFORM6;
- else if (samsung_rev() == EXYNOS4210_REV_1_0)
+ else if (soc_device_match(exynos4210_rev10))
return sysram_base_addr + 0x20;
return pmu_base_addr + S5P_INFORM1;
}
@@ -122,11 +133,13 @@ int exynos_pm_central_resume(void)
}
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
-static void exynos_set_wakeupmask(long mask)
+static void exynos_set_wakeupmask(void)
{
- pmu_raw_writel(mask, S5P_WAKEUP_MASK);
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250")) {
+ pmu_raw_writel(0x40003ffe, S5P_WAKEUP_MASK);
pmu_raw_writel(0x0, S5P_WAKEUP_MASK2);
+ } else
+ pmu_raw_writel(0x0000ff3e, S5P_WAKEUP_MASK);
}
static void exynos_cpu_set_boot_vector(long flags)
@@ -140,7 +153,7 @@ static int exynos_aftr_finisher(unsigned long flags)
{
int ret;
- exynos_set_wakeupmask(soc_is_exynos3250() ? 0x40003ffe : 0x0000ff3e);
+ exynos_set_wakeupmask();
/* Set value of power down register for aftr mode */
exynos_sys_powerdown_conf(SYS_AFTR);
@@ -163,7 +176,7 @@ void exynos_enter_aftr(void)
cpu_pm_enter();
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
exynos_set_boot_flag(cpuid, C2_STATE);
exynos_pm_central_suspend();
@@ -192,7 +205,7 @@ void exynos_enter_aftr(void)
exynos_pm_central_resume();
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
exynos_clear_boot_flag(cpuid, C2_STATE);
cpu_pm_exit();
@@ -263,7 +276,7 @@ abort:
while (exynos_cpu_power_state(1) != S5P_CORE_LOCAL_PWR_EN)
cpu_relax();
- if (soc_is_exynos3250()) {
+ if (of_machine_is_compatible("samsung,exynos3250")) {
while (!pmu_raw_readl(S5P_PMU_SPARE2) &&
!atomic_read(&cpu1_wakeup))
cpu_relax();
@@ -285,7 +298,7 @@ abort:
call_firmware_op(cpu_boot, 1);
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
dsb_sev();
else
arch_send_wakeup_ipi_mask(cpumask_of(1));
@@ -297,7 +310,7 @@ fail:
static int exynos_wfi_finisher(unsigned long flags)
{
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
flush_cache_all();
cpu_do_idle();
@@ -319,7 +332,7 @@ static int exynos_cpu1_powerdown(void)
*/
exynos_cpu_power_down(1);
- if (soc_is_exynos3250())
+ if (of_machine_is_compatible("samsung,exynos3250"))
pmu_raw_writel(0, S5P_PMU_SPARE2);
ret = cpu_suspend(0, exynos_wfi_finisher);
diff --git a/arch/arm/plat-samsung/cpu.c b/arch/arm/plat-samsung/cpu.c
index a107b3a..e58f0f6 100644
--- a/arch/arm/plat-samsung/cpu.c
+++ b/arch/arm/plat-samsung/cpu.c
@@ -21,12 +21,6 @@
unsigned long samsung_cpu_id;
static unsigned int samsung_cpu_rev;
-unsigned int samsung_rev(void)
-{
- return samsung_cpu_rev;
-}
-EXPORT_SYMBOL(samsung_rev);
-
void __init s3c64xx_init_cpu(void)
{
samsung_cpu_id = readl_relaxed(S3C_VA_SYS + 0x118);
@@ -43,11 +37,3 @@ void __init s3c64xx_init_cpu(void)
pr_info("Samsung CPU ID: 0x%08lx\n", samsung_cpu_id);
}
-
-void __init s5p_init_cpu(const void __iomem *cpuid_addr)
-{
- samsung_cpu_id = readl_relaxed(cpuid_addr);
- samsung_cpu_rev = samsung_cpu_id & 0xFF;
-
- pr_info("Samsung CPU ID: 0x%08lx\n", samsung_cpu_id);
-}
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h
index b7b702a..913c176 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -115,8 +115,6 @@ extern void s3c24xx_init_io(struct map_desc *mach_desc, int size);
extern void s3c64xx_init_cpu(void);
extern void s5p_init_cpu(const void __iomem *cpuid_addr);
-extern unsigned int samsung_rev(void);
-
extern void s3c24xx_init_uarts(struct s3c2410_uartcfg *cfg, int no);
extern void s3c24xx_init_clocks(int xtal);
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index 512ed1f..d6853f1 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -13,8 +13,6 @@
#ifndef __ASM_PLAT_MAP_S5P_H
#define __ASM_PLAT_MAP_S5P_H __FILE__
-#define S5P_VA_CHIPID S3C_ADDR(0x02000000)
-
#define VA_VIC(x) (S3C_VA_IRQ + ((x) * 0x10000))
#define VA_VIC0 VA_VIC(0)
#define VA_VIC1 VA_VIC(1)
--
2.7.4
^ permalink raw reply related
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-05 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <963717394.159124.9867e3e7-5710-4844-a098-6f44bd852a6d.open-xchange@email.1und1.de>
Hello Vinod,
as recommanded by Stefan Wahren I'm turning on you about this issue.
Please see below...
On Sat, 2016-11-05 at 12:33 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016
> > um 23:42
> > geschrieben:
> >
> >
> > Hi Stefan,
> >
> > sorry, I forget the link in the previous mail.
> >
> > On Fri, 2016-11-04 at 20:30 +0100, Stefan Wahren wrote:
> > > Hi J?rg,
> > >
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November
> > > > 2016
> > > > um 19:44
> > > > geschrieben:
> > > >
> > > >
> > > > Hi Shawn,
> > > >
> > > > On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > > > > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > > > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29.
> > > > > > > > Oktober
> > > > > > > > 2016
> > > > > > > > um 01:07
> > > > > > > > geschrieben:
> > > > > > > >
> > > > > > > >
> > > > > > > > You mentioned [1] an optimization in the Freescale
> > > > > > > > vendor
> > > > > > > > Linux
> > > > > > > > kernel
> > > > > > > > [2]. I would really like to see this optimization in
> > > > > > > > the
> > > > > > > > mainline
> > > > > > > > kernel.
> > > > > > > >
> > > > > > > > Did you ever tried to port this code from Freescale to
> > > > > > > > mainline?
> > > > > > >
> > > > > > > Yes, i tried once but i was frustrated soon because of
> > > > > > > the
> > > > > > > lot of
> > > > > > > required
> > > > > > > changes and resulting issues.
> > > > > >
> > > > > > I got the PIO mode working for the mxs-mmc driver. For this
> > > > > > I
> > > > > > ported
> > > > > > the PIO code from the vendor kernel and removed the usage
> > > > > > of
> > > > > > the
> > > > > > DMA
> > > > > > engine entirely.
> > > > >
> > > > > Good job
> > > > >
> > > > > >
> > > > > > Testing network bandwidth with iperf, I get about
> > > > > > ~10Mbit/sec
> > > > > > with
> > > > > > PIO
> > > > > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and
> > > > > > about
> > > > > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for
> > > > > > TCP.
> > > > >
> > > > > And how about MMC / sd card performance?
> > > >
> > > > I noticed poor performance with the i.MX28 MMC and/or DMA
> > > > driver
> > > > using
> > > > the mainline kernel compared to the vendor Freescale kernel
> > > > 2.6.35.
> > > > I've seen that hou have added the drivers to mainline some
> > > > years
> > > > ago.
> > > >
> > > > My custom i.MX28 board has a wifi chip attached to the SSP2
> > > > interface.
> > > > Comparing the bandwith with iperf I get >20Mbits/sec on the
> > > > vendor
> > > > kernel and <5Mbits/sec on the mainline kernel.
> > >
> > > there is one thing about the clock handling. I noticed that the
> > > Vendor Kernel
> > > round up the clock frequency and the Mainline Kernel round down
> > > the
> > > clock
> > > frequency [1]. So don't trust the clock ratings from DT / board
> > > code.
> > > Better
> > > verify the register settings or check it with an osci.
> > >
> > > [1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
> >
> > I checked the clock rate setting by reading the register 0x80014070
> > (HW_SSP2_TIMING). CLOCK_DIVIDE is 0x2 and CLOCK_RATE is 0x0. As SSP
> > CLK
> > is 96MHz this makes a clock rate of 48MHz.
> >
> > There was a discussion on the mailing list [1] about that tasklets
> > might be slow.
> >
> > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-Febr
> > uary
> > /043395.html
>
> if i unterstand it right the tasklet is not the problem, but the
> design of the
> MXS DMA driver. Please refer to the chapter "General Design Notes" to
> the
> documentation of the DMA provider [2].
> I think the MXS DMA driver is affected. Maybe you should ask Vinod
> Koul about
> this.
>
> [2] - https://www.kernel.org/doc/Documentation/dmaengine/provider.txt
@ Vinod
In short, I noticed poor performance in the SSP2 (MMC/SD/SDIO)
interface on a custom i.MX28 board with a wifi chip attached. Comparing
the bandwith with iperf I get >20Mbits/sec on the vendor kernel and
<5Mbits/sec on the mainline kernel. I am trying to investigate what the
bottleneck is.
@ Stefan, all
My understanding is that the tasklet in this case is responsible for
reading the response registers of the DMA controller and return the
response to the MMC host driver.
The vendor kernel does this in the interrupt routine of mxs-mmc by
issueing a complete whereas the mainline kernel does this in the
interrupt routine in mxs-dma by scheduling the tasklet.
To check if this makes any difference I replaced the tasklet() usage
with using the complete() infrastructure. For this I hacked the DMA
engine and the MXS DMA driver. However, the performance stays the same.
So, if I understand correctly, this is not an issue here, right? So if
not the tasklet, what do you suspect?
J?rg
^ permalink raw reply
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