* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-08 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ebadfacf-73fb-01a6-791a-324daad5e695@st.com>
2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@st.com>:
> Hi Rados?aw
>
> Many thanks for reviewing.
>
> On 11/07/2016 03:57 PM, Rados?aw Pietrzyk wrote:
>>>
>>> +static struct clk_hw *clk_register_pll_div(const char *name,
>>> + const char *parent_name, unsigned long flags,
>>> + void __iomem *reg, u8 shift, u8 width,
>>> + u8 clk_divider_flags, const struct clk_div_table *table,
>>> + struct clk_hw *pll_hw, spinlock_t *lock)
>>> +{
>>> + struct stm32f4_pll_div *pll_div;
>>> + struct clk_hw *hw;
>>> + struct clk_init_data init;
>>> + int ret;
>>> +
>>> + /* allocate the divider */
>>> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
>>> + if (!pll_div)
>>> + return ERR_PTR(-ENOMEM);
>>> +
>>> + init.name = name;
>>> + init.ops = &stm32f4_pll_div_ops;
>>> + init.flags = flags;
>>
>> Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
>> should have CLK_SET_RATE_GATE flag and we can get rid of custom
>> divider ops.
>
> I don't want to offer the possibility to change the vco clock through the
> divisor of the pll (only by a boot-loader or by DT).
>
> e.g. if i make a set rate on lcd-tft clock, i don't want to change the SAI
> frequencies.
>
> I used same structure for internal divisors of the pll (p, q, r) and for
> post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
> That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
>
> These divisors are similar because we have to switch off the pll before
> changing the rate.
>
But changing pll and lcd dividers only may not be enough for getting
very specific pixelclocks and that might require changing the VCO
frequency itself. The rest of the SAI tree should be recalculated
then.
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Peter De Schrijver @ 2016-11-08 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13e7ff98-8bc2-ccf7-94bb-4e1d3c61b20d@nvidia.com>
On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>
> On 07/11/16 13:28, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> >
> > On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
> >> Nyan boards only have host USB ports (2 external, 1 internal), there is
> >> no OTG-enabled connector.
> >>
> >> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >> ---
> >> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Where is this information coming from? I don't have one of the Nyans
> > myself, but one of the Tegra132 devices I have, which I think was
> > derived from one of the Nyans uses one of the external host ports as
> > forced recovery port, for which it would need OTG.
> >
> > I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> > In that case I think one of the ports must be OTG.
>
> It is true that the port on the back on the nyan-big can be used with
> recovery mode. I was thinking that this is not a true OTG port as it is
> just a 4-pin type A socket and does not have an ID pin. Thinking some
> more about this the USB spec does include a "Host Negotiation Protocol
> (HNP)" that allows a host and device to swap roles and so keeping it as
> OTG seems valid afterall.
I don't think the bootrom implements that though. I expect recovery mode
to just program the controller in device mode, without performing any
negotiation.
Peter.
^ permalink raw reply
* [PATCH 5/5] drm/sun4i: Add support for the overscan profiles
From: Daniel Vetter @ 2016-11-08 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b980759ad766658d7bc3d67c18f505c5bf727ef5.1476779323.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote:
> Create overscan profiles reducing the displayed zone.
>
> For each TV standard (PAL and NTSC so far), we create 4 more reduced modes
> by steps of 5% that the user will be able to select.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
tbh I think if we agree to do this (and that still seems an open question)
I think there should be a generic helper to add these overscan modes with
increased porches. Anything that only depends upon the sink (and
overscanning is something the sink does) should imo be put into a suitable
helper library for everyone to share.
Or maybe even stash it into the probe helpers and call it for all TV
connectors. Definitely not a driver-private thing.
-Daniel
> ---
> drivers/gpu/drm/sun4i/sun4i_tv.c | 60 +++++++++++++++++++--------------
> 1 file changed, 36 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index f99886462cb8..9ee03ba086b6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -301,27 +301,33 @@ static const struct tv_mode *sun4i_tv_find_tv_by_mode(const struct drm_display_m
> DRM_DEBUG_DRIVER("Comparing mode %s vs %s",
> mode->name, tv_mode->name);
>
> - if (!strcmp(mode->name, tv_mode->name))
> + if (!strncmp(mode->name, tv_mode->name, strlen(tv_mode->name)))
> return tv_mode;
> }
>
> /* Then by number of lines */
> for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> const struct tv_mode *tv_mode = &tv_modes[i];
> + int j;
>
> - DRM_DEBUG_DRIVER("Comparing mode %s vs %s (X: %d vs %d)",
> - mode->name, tv_mode->name,
> - mode->vdisplay, tv_mode->vdisplay);
> + for (j = 0; j < 20; j += 5) {
> + u32 vdisplay = tv_mode->vdisplay * (100 - j) / 100;
>
> - if (mode->vdisplay == tv_mode->vdisplay)
> - return tv_mode;
> + DRM_DEBUG_DRIVER("Comparing mode with %s (%d) (X: %d vs %d)",
> + tv_mode->name, j,
> + vdisplay, tv_mode->vdisplay);
> +
> + if (vdisplay == tv_mode->vdisplay)
> + return tv_mode;
> + }
> }
>
> return NULL;
> }
>
> static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
> - struct drm_display_mode *mode)
> + struct drm_display_mode *mode,
> + int overscan)
> {
> DRM_DEBUG_DRIVER("Creating mode %s\n", mode->name);
>
> @@ -329,12 +335,12 @@ static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
> mode->clock = 13500;
> mode->flags = DRM_MODE_FLAG_INTERLACE;
>
> - mode->hdisplay = tv_mode->hdisplay;
> + mode->hdisplay = tv_mode->hdisplay * (100 - overscan) / 100;
> mode->hsync_start = mode->hdisplay + tv_mode->hfront_porch;
> mode->hsync_end = mode->hsync_start + tv_mode->hsync_len;
> mode->htotal = mode->hsync_end + tv_mode->hback_porch;
>
> - mode->vdisplay = tv_mode->vdisplay;
> + mode->vdisplay = tv_mode->vdisplay * (100 - overscan) / 100;
> mode->vsync_start = mode->vdisplay + tv_mode->vfront_porch;
> mode->vsync_end = mode->vsync_start + tv_mode->vsync_len;
> mode->vtotal = mode->vsync_end + tv_mode->vback_porch;
> @@ -352,10 +358,10 @@ static int sun4i_tv_atomic_check(struct drm_encoder *encoder,
> return -EINVAL;
>
> state->display_x_size = tv_mode->hdisplay;
> - state->plane_x_offset = 0;
> + state->plane_x_offset = (tv_mode->hdisplay - mode->hdisplay) / 2;
>
> state->display_y_size = tv_mode->vdisplay;
> - state->plane_y_offset = 0;
> + state->plane_y_offset = (tv_mode->vdisplay - mode->vdisplay) / 2;
>
> return 0;
> }
> @@ -404,7 +410,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
> struct drm_display_mode tv_drm_mode = { 0 };
>
> strcpy(tv_drm_mode.name, "TV");
> - sun4i_tv_mode_to_drm_mode(tv_mode, &tv_drm_mode);
> + sun4i_tv_mode_to_drm_mode(tv_mode, &tv_drm_mode, 0);
> drm_mode_set_crtcinfo(&tv_drm_mode, CRTC_INTERLACE_HALVE_V);
>
> sun4i_tcon1_mode_set(tcon, &tv_drm_mode);
> @@ -526,22 +532,28 @@ static int sun4i_tv_comp_get_modes(struct drm_connector *connector)
> int i;
>
> for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> - struct drm_display_mode *mode;
> const struct tv_mode *tv_mode = &tv_modes[i];
> -
> - mode = drm_mode_create(connector->dev);
> - if (!mode) {
> - DRM_ERROR("Failed to create a new display mode\n");
> - return 0;
> + int j;
> +
> + for (j = 0; j < 20; j += 5) {
> + struct drm_display_mode *mode = drm_mode_create(connector->dev);
> + if (!mode) {
> + DRM_ERROR("Failed to create a new display mode\n");
> + return 0;
> + }
> +
> + if (j)
> + sprintf(mode->name, "%s%d", tv_mode->name,
> + j);
> + else
> + strcpy(mode->name, tv_mode->name);
> +
> + sun4i_tv_mode_to_drm_mode(tv_mode, mode, j);
> + drm_mode_probed_add(connector, mode);
> }
> -
> - strcpy(mode->name, tv_mode->name);
> -
> - sun4i_tv_mode_to_drm_mode(tv_mode, mode);
> - drm_mode_probed_add(connector, mode);
> }
>
> - return i;
> + return i * 4;
> }
>
> static int sun4i_tv_comp_mode_valid(struct drm_connector *connector,
> --
> git-series 0.8.10
> _______________________________________________
> 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] ARM: tegra: nyan: Mark all USB ports as host
From: Paul Kocialkowski @ 2016-11-08 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108085420.GG2478@tbergstrom-lnx.Nvidia.com>
Le mardi 08 novembre 2016 ? 10:54 +0200, Peter De Schrijver a ?crit?:
> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
> >
> > On 07/11/16 13:28, Thierry Reding wrote:
> > > * PGP Signed by an unknown key
> > >
> > > On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
> > > > Nyan boards only have host USB ports (2 external, 1 internal), there is
> > > > no OTG-enabled connector.
> > > >
> > > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > > > ---
> > > > ?arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> > > > ?1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Where is this information coming from? I don't have one of the Nyans
> > > myself, but one of the Tegra132 devices I have, which I think was
> > > derived from one of the Nyans uses one of the external host ports as
> > > forced recovery port, for which it would need OTG.
> > >
> > > I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> > > In that case I think one of the ports must be OTG.
> >
> > It is true that the port on the back on the nyan-big can be used with
> > recovery mode. I was thinking that this is not a true OTG port as it is
> > just a 4-pin type A socket and does not have an ID pin. Thinking some
> > more about this the USB spec does include a "Host Negotiation Protocol
> > (HNP)" that allows a host and device to swap roles and so keeping it as
> > OTG seems valid afterall.
>
> I don't think the bootrom implements that though. I expect recovery mode
> to just program the controller in device mode, without performing any
> negotiation.
That would make sense.
However, if there's a way (even not implemented yet, but a possible way) to have
the kernel configure this port as USB device instead of host dynamically (e.g.
without changing this bit in the dts), then I think it makes sense to keep the
OTG marking and drop this patch.
After all, switching to USB device mode doesn't necessarily have to come from
the ID pin.
--
Paul Kocialkowski, developer of free digital technology at the lower levels
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/66a1f1dd/attachment.sig>
^ permalink raw reply
* [PATCH v4] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-08 9:11 UTC (permalink / raw)
To: linux-arm-kernel
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
Changes in v4:
- move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
drivers/devfreq/devfreq.c | 15 +++++++++++++--
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 9 +++++++++
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index bf3ea76..d9d56e1 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
+ if (devfreq->suspend_freq) {
+ update_devfreq(devfreq);
+ devfreq->suspend_flag = true;
+ }
devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(&devfreq->lock);
@@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
devfreq->last_stat_updated = jiffies;
devfreq->stop_polling = false;
-
+ if (devfreq->suspend_freq)
+ devfreq->suspend_flag = false;
if (devfreq->profile->get_cur_freq &&
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
devfreq->previous_freq = freq;
@@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq *devfreq;
struct devfreq_governor *governor;
int err = 0;
+ struct dev_pm_opp *suspend_opp;
if (!dev || !profile || !governor_name) {
dev_err(dev, "%s: Invalid parameters.\n", __func__);
@@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
devfreq_set_freq_table(devfreq);
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..84b3ce1 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->suspend_flag) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 2de4e2e..c463ae1 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
@@ -179,6 +180,7 @@ struct devfreq {
unsigned long min_freq;
unsigned long max_freq;
bool stop_polling;
+ bool suspend_flag;
/* information for device frequency transition */
unsigned int total_trans;
@@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
/* Helper functions for devfreq user device driver with OPP. */
extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+ struct devfreq *devfreq);
extern int devfreq_register_opp_notifier(struct device *dev,
struct devfreq *devfreq);
extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
}
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+ struct devfreq *devfreq)
+{
+}
+
static inline int devfreq_register_opp_notifier(struct device *dev,
struct devfreq *devfreq)
{
--
2.6.6
^ permalink raw reply related
* [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: Felipe Balbi @ 2016-11-08 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e99e9d8df77884671f94734109a1a8d76a0222c1.1478558343.git.johnyoun@synopsys.com>
Hi,
John Youn <johnyoun@synopsys.com> writes:
> Add a vendor prefix and make the name more consistent by renaming it to
> "snps,gadget-dma-enable".
>
> Signed-off-by: John Youn <johnyoun@synopsys.com>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
> arch/arm/boot/dts/rk3036.dtsi | 2 +-
> arch/arm/boot/dts/rk3288.dtsi | 2 +-
> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
> drivers/usb/dwc2/params.c | 9 ++++++++-
> drivers/usb/dwc2/pci.c | 2 +-
> 8 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> index 9472111..389a461 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
> - dr_mode: shall be one of "host", "peripheral" and "otg"
> Refer to usb/generic.txt
> - snps,host-dma-disable: disable host DMA mode.
> -- g-use-dma: enable dma usage in gadget driver.
> +- snps,gadget-dma-enable: enable gadget DMA mode.
I don't see why you even have this binding. Looking through the code,
you have:
#define GHWCFG2_SLAVE_ONLY_ARCH 0
#define GHWCFG2_EXT_DMA_ARCH 1
#define GHWCFG2_INT_DMA_ARCH 2
void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
{
int valid = 1;
if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
valid = 0;
if (val < 0)
valid = 0;
if (!valid) {
if (val >= 0)
dev_err(hsotg->dev,
"%d invalid for dma_enable parameter. Check HW configuration.\n",
val);
val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
}
hsotg->core_params->dma_enable = val;
}
which seems to hint that DMA support is discoverable. If there is DMA,
why would disable it?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/28908c8d/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-08 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108070851.GA15044@sha-win-210.asiapac.arm.com>
Hi Gerald,
On Tue, Nov 08, 2016 at 03:08:52PM +0800, Huang Shijie wrote:
> On Tue, Nov 08, 2016 at 10:19:30AM +0800, Huang Shijie wrote:
> > On Mon, Nov 07, 2016 at 04:25:04PM +0100, Gerald Schaefer wrote:
> > > On Thu, 3 Nov 2016 10:51:38 +0800
> > > Huang Shijie <shijie.huang@arm.com> wrote:
> > >
> > > > When testing the gigantic page whose order is too large for the buddy
> > > > allocator, the libhugetlbfs test case "counter.sh" will fail.
> > > >
> > > > The failure is caused by:
> > > > 1) kernel fails to allocate a gigantic page for the surplus case.
> > > > And the gather_surplus_pages() will return NULL in the end.
> > > >
> > > > 2) The condition checks for "over-commit" is wrong.
> > > >
> > > > This patch adds code to allocate the gigantic page in the
> > > > __alloc_huge_page(). After this patch, gather_surplus_pages()
> > > > can return a gigantic page for the surplus case.
> > > >
> > > > This patch also changes the condition checks for:
> > > > return_unused_surplus_pages()
> > > > nr_overcommit_hugepages_store()
> > > >
> > > > After this patch, the counter.sh can pass for the gigantic page.
> > > >
> > > > Acked-by: Steve Capper <steve.capper@arm.com>
> > > > Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> > > > ---
> > > > mm/hugetlb.c | 15 ++++++++++-----
> > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > index 0bf4444..2b67aff 100644
> > > > --- a/mm/hugetlb.c
> > > > +++ b/mm/hugetlb.c
> > > > @@ -1574,7 +1574,7 @@ static struct page *__alloc_huge_page(struct hstate *h,
> > > > struct page *page;
> > > > unsigned int r_nid;
> > > >
> > > > - if (hstate_is_gigantic(h))
> > > > + if (hstate_is_gigantic(h) && !gigantic_page_supported())
> > > > return NULL;
> > >
> > > Is it really possible to stumble over gigantic pages w/o having
> > > gigantic_page_supported()?
> > >
> > > Also, I've just tried this on s390 and counter.sh still fails after these
> > > patches, and it should fail on all archs as long as you use the gigantic
> > I guess the failure you met is caused by the libhugetlbfs itself, there are
> > several bugs in the libhugetlbfs. I have a patch set for the
> > libhugetlbfs too. I will send it as soon as possible.
> >
> > > hugepage size as default hugepage size. This is because you only changed
> > > nr_overcommit_hugepages_store(), which handles nr_overcommit_hugepages
> > > in sysfs, and missed hugetlb_overcommit_handler() which handles
> > > /proc/sys/vm/nr_overcommit_hugepages for the default sized hugepages.
> > This is wrong. :)
> Sorry, I was wrong :). The counters test does call the /proc/sys/vm/nr_overcommit_hugepages.
> But in the arm64, it does not trigger a fail for the counters test.
> In an other word, I did not change the hugetlb_overcommit_handler(),
> the counters.sh also can pass in arm64.
After I add the "default_hugepagesz=32M" to the kernel cmdlin, I can
reproduce this issue. Thanks for point this.
>
> I will look at the lockdep issue.
I tested the new patch (will be sent out later) on the arm64 platform,
and I did not meet the lockdep issue when I enabled the lockdep.
The following is my config:
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
So do I miss something?
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH] pinctrl: sx150x: fix up headers
From: Linus Walleij @ 2016-11-08 9:27 UTC (permalink / raw)
To: linux-arm-kernel
Include <linux/gpio/driver.h> rather than <linux/gpio.h>
Drop <linux/pinctrl/machine.h>.
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-sx150x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index dc1341fdc73d..63778058eec7 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -27,8 +27,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/gpio.h>
-#include <linux/pinctrl/machine.h>
+#include <linux/gpio/driver.h>
#include <linux/pinctrl/pinconf.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
--
2.7.4
^ permalink raw reply related
* [PATCH v4] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-11-08 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478596289-7442-1-git-send-email-hl@rock-chips.com>
Hi Lin,
On 2016? 11? 08? 18:11, Lin Huang wrote:
> Add suspend frequency support and if needed set it to
> the frequency obtained from the suspend opp (can be defined
> using opp-v2 bindings and is optional).
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - use update_devfreq() instead devfreq_update_status()
> Changes in v3:
> - fix build error
> Changes in v4:
> - move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
>
> drivers/devfreq/devfreq.c | 15 +++++++++++++--
> drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
> include/linux/devfreq.h | 9 +++++++++
> 3 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index bf3ea76..d9d56e1 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> mutex_unlock(&devfreq->lock);
> return;
> }
> -
> + if (devfreq->suspend_freq) {
> + update_devfreq(devfreq);
> + devfreq->suspend_flag = true;
You don't need the additional variable (devfreq->suspend_flag).
When adding the devfreq on devfreq_add_device(),
you can initialize the devfreq->suspend_freq as zero(0).
You can check whether devfreq->suspend_freq is 0 or not
without the new suspend_flag.
> + }
> devfreq_update_status(devfreq, devfreq->previous_freq);
> devfreq->stop_polling = true;
> mutex_unlock(&devfreq->lock);
> @@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>
> devfreq->last_stat_updated = jiffies;
> devfreq->stop_polling = false;
> -
> + if (devfreq->suspend_freq)
> + devfreq->suspend_flag = false;
ditto. You don't need to add this code.
> if (devfreq->profile->get_cur_freq &&
> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> devfreq->previous_freq = freq;
> @@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> struct devfreq *devfreq;
> struct devfreq_governor *governor;
> int err = 0;
> + struct dev_pm_opp *suspend_opp;
>
> if (!dev || !profile || !governor_name) {
> dev_err(dev, "%s: Invalid parameters.\n", __func__);
> @@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
>
> + rcu_read_lock();
> + suspend_opp = dev_pm_opp_get_suspend_opp(dev);
> + if (suspend_opp)
> + devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
> + rcu_read_unlock();
> +
> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> mutex_unlock(&devfreq->lock);
> devfreq_set_freq_table(devfreq);
> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
> index ae72ba5..84b3ce1 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> struct devfreq_simple_ondemand_data *data = df->data;
> unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>
> + /*
> + * if devfreq in suspend status and have suspend_freq,
> + * the frequency need to set to suspend_freq
> + */
> + if (df->suspend_flag) {
> + *freq = df->suspend_freq;
> + return 0;
> + }
You can check it as following:
if (df->suspend_freq != 0)
*freq = df->suspend_freq;
> +
> err = devfreq_update_stats(df);
> if (err)
> return err;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 2de4e2e..c463ae1 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -172,6 +172,7 @@ struct devfreq {
> struct delayed_work work;
>
> unsigned long previous_freq;
> + unsigned long suspend_freq;
> struct devfreq_dev_status last_status;
>
> void *data; /* private data for governors */
> @@ -179,6 +180,7 @@ struct devfreq {
> unsigned long min_freq;
> unsigned long max_freq;
> bool stop_polling;
> + bool suspend_flag;
You don't need to add new variable.
>
> /* information for device frequency transition */
> unsigned int total_trans;
> @@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
> /* Helper functions for devfreq user device driver with OPP. */
> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> unsigned long *freq, u32 flags);
> +extern void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq);
Why do you need this function? Also, this patch don't include the body
of devfreq_opp_get_suspend_opp() function.
> extern int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq);
> extern int devfreq_unregister_opp_notifier(struct device *dev,
> @@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> return ERR_PTR(-EINVAL);
> }
>
> +static inline void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq)
> +{
> +}
> +
> static inline int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq)
> {
>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v3 1/5] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
From: Linus Walleij @ 2016-11-08 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-2-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 3, 2016 at 7:39 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch supports the multiple IORESOURCE_MEM resources for one pin-bank.
> In the pre-existing Exynos series, the registers of the gpio bank are included
> in the one memory map. But, some gpio bank need to support the one more memory
> map (IORESOURCE_MEM) because the registers of gpio bank are separated into
> the different memory map.
>
> For example,
> The both ALIVE and IMEM domain have the different memory base address.
> The GFP[1-5] of exynos5433 are composed as following:
> - ALIVE domain : WEINT_* registers
> - IMEM domain : CON/DAT/PUD/DRV/CONPDN/PUDPDN register
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio at vger.kernel.org
> Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Patch applied with Krzysztof's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Linus Walleij @ 2016-11-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-3-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 3, 2016 at 7:39 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
> to support the multiple memory map because the registers of GPFx are located
> in the different domain.
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Linus Walleij @ 2016-11-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103192002.GB12945@kozik-lap>
On Thu, Nov 3, 2016 at 8:20 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Nov 03, 2016 at 03:39:06PM +0900, Chanwoo Choi wrote:
>> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
>> to support the multiple memory map because the registers of GPFx are located
>> in the different domain.
>>
>> Cc: Tomasz Figa <tomasz.figa@gmail.com>
>> Cc: Krzysztof Kozlowski <krzk@kernel.org>
>> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Cc: Kukjin Kim <kgene@kernel.org>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-gpio at vger.kernel.org
>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>
> I think that, instead of in previous patch, the
> "samsung,exynos5433-pinctrl" compatible should be documented here along
> with information that it requires two addresses for mappings.
True but too small detail to respin the patches about,
and I'm not perfectionist, so patch applied anyways.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-08 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108085420.GG2478@tbergstrom-lnx.Nvidia.com>
On 08/11/16 08:54, Peter De Schrijver wrote:
> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>>
>> On 07/11/16 13:28, Thierry Reding wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>>>> no OTG-enabled connector.
>>>>
>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>> ---
>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Where is this information coming from? I don't have one of the Nyans
>>> myself, but one of the Tegra132 devices I have, which I think was
>>> derived from one of the Nyans uses one of the external host ports as
>>> forced recovery port, for which it would need OTG.
>>>
>>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
>>> In that case I think one of the ports must be OTG.
>>
>> It is true that the port on the back on the nyan-big can be used with
>> recovery mode. I was thinking that this is not a true OTG port as it is
>> just a 4-pin type A socket and does not have an ID pin. Thinking some
>> more about this the USB spec does include a "Host Negotiation Protocol
>> (HNP)" that allows a host and device to swap roles and so keeping it as
>> OTG seems valid afterall.
>
> I don't think the bootrom implements that though. I expect recovery mode
> to just program the controller in device mode, without performing any
> negotiation.
I am not talking about the bootrom and I would not expect the bootrom to
do that. However, the kernel could.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Adrian Hunter @ 2016-11-08 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478018277-10097-3-git-send-email-scott.branden@broadcom.com>
On 01/11/16 18:37, Scott Branden wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
This is unchanged from V1 which I acked, so:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
^ permalink raw reply
* [PATCH v4] PM/devfreq: add suspend frequency support
From: hl @ 2016-11-08 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58219B96.6060106@samsung.com>
Hi Chanwoo Choi,
On 2016?11?08? 17:32, Chanwoo Choi wrote:
> Hi Lin,
>
> On 2016? 11? 08? 18:11, Lin Huang wrote:
>> Add suspend frequency support and if needed set it to
>> the frequency obtained from the suspend opp (can be defined
>> using opp-v2 bindings and is optional).
>>
>> Signed-off-by: Lin Huang <hl@rock-chips.com>
>> ---
>> Changes in v2:
>> - use update_devfreq() instead devfreq_update_status()
>> Changes in v3:
>> - fix build error
>> Changes in v4:
>> - move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
>>
>> drivers/devfreq/devfreq.c | 15 +++++++++++++--
>> drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
>> include/linux/devfreq.h | 9 +++++++++
>> 3 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index bf3ea76..d9d56e1 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
>> mutex_unlock(&devfreq->lock);
>> return;
>> }
>> -
>> + if (devfreq->suspend_freq) {
>> + update_devfreq(devfreq);
>> + devfreq->suspend_flag = true;
> You don't need the additional variable (devfreq->suspend_flag).
> When adding the devfreq on devfreq_add_device(),
> you can initialize the devfreq->suspend_freq as zero(0).
>
> You can check whether devfreq->suspend_freq is 0 or not
> without the new suspend_flag.
>
>> + }
>> devfreq_update_status(devfreq, devfreq->previous_freq);
>> devfreq->stop_polling = true;
>> mutex_unlock(&devfreq->lock);
>> @@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>>
>> devfreq->last_stat_updated = jiffies;
>> devfreq->stop_polling = false;
>> -
>> + if (devfreq->suspend_freq)
>> + devfreq->suspend_flag = false;
> ditto. You don't need to add this code.
>
>> if (devfreq->profile->get_cur_freq &&
>> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
>> devfreq->previous_freq = freq;
>> @@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> struct devfreq *devfreq;
>> struct devfreq_governor *governor;
>> int err = 0;
>> + struct dev_pm_opp *suspend_opp;
>>
>> if (!dev || !profile || !governor_name) {
>> dev_err(dev, "%s: Invalid parameters.\n", __func__);
>> @@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> devfreq->data = data;
>> devfreq->nb.notifier_call = devfreq_notifier_call;
>>
>> + rcu_read_lock();
>> + suspend_opp = dev_pm_opp_get_suspend_opp(dev);
>> + if (suspend_opp)
>> + devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
>> + rcu_read_unlock();
>> +
>> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
>> mutex_unlock(&devfreq->lock);
>> devfreq_set_freq_table(devfreq);
>> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
>> index ae72ba5..84b3ce1 100644
>> --- a/drivers/devfreq/governor_simpleondemand.c
>> +++ b/drivers/devfreq/governor_simpleondemand.c
>> @@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
>> struct devfreq_simple_ondemand_data *data = df->data;
>> unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>>
>> + /*
>> + * if devfreq in suspend status and have suspend_freq,
>> + * the frequency need to set to suspend_freq
>> + */
>> + if (df->suspend_flag) {
>> + *freq = df->suspend_freq;
>> + return 0;
>> + }
> You can check it as following:
>
> if (df->suspend_freq != 0)
> *freq = df->suspend_freq;
If i do like this, it will always return suspend frequency, since
devfreq->suspend_freq will be assigned value
if we define it on dts. But what we want is only in suspend status we
return the suspend frequency.
>
>> +
>> err = devfreq_update_stats(df);
>> if (err)
>> return err;
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index 2de4e2e..c463ae1 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -172,6 +172,7 @@ struct devfreq {
>> struct delayed_work work;
>>
>> unsigned long previous_freq;
>> + unsigned long suspend_freq;
>> struct devfreq_dev_status last_status;
>>
>> void *data; /* private data for governors */
>> @@ -179,6 +180,7 @@ struct devfreq {
>> unsigned long min_freq;
>> unsigned long max_freq;
>> bool stop_polling;
>> + bool suspend_flag;
> You don't need to add new variable.
>
>>
>> /* information for device frequency transition */
>> unsigned int total_trans;
>> @@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
>> /* Helper functions for devfreq user device driver with OPP. */
>> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
>> unsigned long *freq, u32 flags);
>> +extern void devfreq_opp_get_suspend_opp(struct device *dev,
>> + struct devfreq *devfreq);
> Why do you need this function? Also, this patch don't include the body
> of devfreq_opp_get_suspend_opp() function.
Oh, forget to delete it, sorry about that.
>
>> extern int devfreq_register_opp_notifier(struct device *dev,
>> struct devfreq *devfreq);
>> extern int devfreq_unregister_opp_notifier(struct device *dev,
>> @@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
>> return ERR_PTR(-EINVAL);
>> }
>>
>> +static inline void devfreq_opp_get_suspend_opp(struct device *dev,
>> + struct devfreq *devfreq)
>> +{
>> +}
>> +
>> static inline int devfreq_register_opp_notifier(struct device *dev,
>> struct devfreq *devfreq)
>> {
>>
--
Lin Huang
^ permalink raw reply
* [PATCH 2/2] irqchip/gicv3-its: Test code for measuring Read-allocate
From: kbuild test robot @ 2016-11-08 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c3ea714-5bd2-6784-8eae-8b953860c8f6@codeaurora.org>
Hi Shanker,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.9-rc4 next-20161028]
[cannot apply to tip/irq/core arm-jcooper/irqchip/core]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shanker-Donthineni/irqchip-gicv3-its-Test-code-for-measuring-Read-allocate/20161108-154723
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
/tmp/ccEUFgcT.s: Assembler messages:
>> /tmp/ccEUFgcT.s:700: Error: selected processor does not support requested special purpose register -- `mrs r10,pmccntr_el0'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 38721 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/f74b1c64/attachment-0001.gz>
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Matthias Brugger @ 2016-11-08 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108004642.GB32444@obsidianresearch.com>
On 11/08/2016 01:46 AM, Jason Gunthorpe wrote:
> On Fri, Oct 28, 2016 at 05:09:26PM -0700, Moritz Fischer wrote:
>
>> That being said, I don't like the idea of the driver having to search
>> either...
>
> I think we are stuck with that, considering what Xilinx tools
> produce..
>
> Here is a v2, what do you think?
>
> From 93ffde371ca50809ba9b4cdca17051a050b0f92d Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Date: Wed, 26 Oct 2016 16:51:26 -0600
> Subject: [PATCH v2] fpga zynq: Check the bitstream for validity
>
> There is no sense in sending a bitstream we know will not work, and
> with the variety of options for bitstream generation in Xilinx tools
> it is not terribly clear or very well documented what the correct
> input should be, especially since auto-detection was removed from this
> driver.
>
> All Zynq full configuration bitstreams must start with the sync word in
> the correct byte order.
>
> Zynq is also only able to DMA dword quantities, so bitstreams must be
> a multiple of 4 bytes. This also fixes a DMA-past the end bug.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/zynq-fpga.c | 35 ++++++++++++++++++++++++++---------
> 1 file changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> index c2fb4120bd62..de475a6a1882 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -175,6 +175,19 @@ static irqreturn_t zynq_fpga_isr(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +/* Sanity check the proposed bitstream. It must start with the sync word in
> + * the correct byte order. The input is a Xilinx .bin file with every 32 bit
> + * quantity swapped.
> + */
> +static bool zynq_fpga_has_sync(const char *buf, size_t count)
> +{
> + for (; count > 4; buf += 4, --count)
> + if (buf[0] == 0x66 && buf[1] == 0x55 && buf[2] == 0x99 &&
> + buf[3] == 0xaa)
> + return true;
> + return false;
> +}
> +
> static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> const char *buf, size_t count)
> {
> @@ -184,12 +197,23 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>
> priv = mgr->priv;
>
> + /* The hardware can only DMA multiples of 4 bytes, and we need at
> + * least the sync word and something else to do anything.
> + */
> + if (count <= 4 || (count % 4) != 0)
> + return -EINVAL;
> +
> err = clk_enable(priv->clk);
> if (err)
> return err;
>
> /* don't globally reset PL if we're doing partial reconfig */
> if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + if (!zynq_fpga_has_sync(buf, count)) {
Maybe we should add an error message here to let the user know what went
wrong, as I think this error path could easily be hit by an user.
Regards,
Matthias
> + err = -EINVAL;
> + goto out_err;
> + }
> +
> /* assert AXI interface resets */
> regmap_write(priv->slcr, SLCR_FPGA_RST_CTRL_OFFSET,
> FPGA_RST_ALL_MASK);
> @@ -287,12 +311,9 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> struct zynq_fpga_priv *priv;
> int err;
> char *kbuf;
> - size_t in_count;
> dma_addr_t dma_addr;
> - u32 transfer_length;
> u32 intr_status;
>
> - in_count = count;
> priv = mgr->priv;
>
> kbuf = dma_alloc_coherent(priv->dev, count, &dma_addr, GFP_KERNEL);
> @@ -318,11 +339,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> */
> zynq_fpga_write(priv, DMA_SRC_ADDR_OFFSET, (u32)(dma_addr) + 1);
> zynq_fpga_write(priv, DMA_DST_ADDR_OFFSET, (u32)DMA_INVALID_ADDRESS);
> -
> - /* convert #bytes to #words */
> - transfer_length = (count + 3) / 4;
> -
> - zynq_fpga_write(priv, DMA_SRC_LEN_OFFSET, transfer_length);
> + zynq_fpga_write(priv, DMA_SRC_LEN_OFFSET, count / 4);
> zynq_fpga_write(priv, DMA_DEST_LEN_OFFSET, 0);
>
> wait_for_completion(&priv->dma_done);
> @@ -338,7 +355,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> clk_disable(priv->clk);
>
> out_free:
> - dma_free_coherent(priv->dev, in_count, kbuf, dma_addr);
> + dma_free_coherent(priv->dev, count, kbuf, dma_addr);
>
> return err;
> }
>
^ permalink raw reply
* [PATCH v5] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-08 10:06 UTC (permalink / raw)
To: linux-arm-kernel
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
Changes in v4:
- move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
Changes in v5:
- delete devfreq_opp_get_suspend_opp() in devfreq.h
drivers/devfreq/devfreq.c | 15 +++++++++++++--
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 2 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..af06891 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,7 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
+ if (devfreq->suspend_freq) {
+ update_devfreq(devfreq);
+ devfreq->suspend_flag = true;
+ }
devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(&devfreq->lock);
@@ -390,7 +393,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
devfreq->last_stat_updated = jiffies;
devfreq->stop_polling = false;
-
+ if (devfreq->suspend_freq)
+ devfreq->suspend_flag = false;
if (devfreq->profile->get_cur_freq &&
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
devfreq->previous_freq = freq;
@@ -524,6 +528,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq *devfreq;
struct devfreq_governor *governor;
int err = 0;
+ struct dev_pm_opp *suspend_opp;
if (!dev || !profile || !governor_name) {
dev_err(dev, "%s: Invalid parameters.\n", __func__);
@@ -558,6 +563,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
devfreq_set_freq_table(devfreq);
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..84b3ce1 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->suspend_flag) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..8567153 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
@@ -179,6 +180,7 @@ struct devfreq {
unsigned long min_freq;
unsigned long max_freq;
bool stop_polling;
+ bool suspend_flag;
/* information for device frequency transition */
unsigned int total_trans;
--
2.6.6
^ permalink raw reply related
* [PATCH 1/1] pinctrl: st: st_pinconf_dbg_show wrong format string
From: Linus Walleij @ 2016-11-08 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105142515.4377-1-xypron.glpk@gmx.de>
On Sat, Nov 5, 2016 at 3:25 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> function is defined as unsigned int.
> So we need %u to print it.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Patch applied with Patrice's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: acpi: arch_apei_get_mem_attributes() should use memblock
From: James Morse @ 2016-11-08 10:27 UTC (permalink / raw)
To: linux-arm-kernel
arm64's arch_apei_get_mem_attributes() tries to use
efi_mem_attributes() to read the memory attributes from the efi
memory map.
drivers/firmware/efi/arm-init.c:efi_init() calls efi_memmap_unmap(),
which clears the EFI_MEMMAP bit from efi.flags once efi_init() has
finished with the memory map. This causes efi_mem_attributes() to
return 0 meaning PROT_DEVICE_nGnRnE is the chosen memory type for
all ACPI APEI mappings.
APEI may call this from NMI context, so we can't re-map the EFI
memory map as this may need to allocate virtual address space.
'ghes_ioremap_area' is APEIs cache of virtual address space to
access the buffer once we tell it the memory attributes.
Do as acpi_os_ioremap() does, and consult memblock to learn if
the provided address is memory, or not.
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Fixes: 89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()")
This doesn't code even get built on mainline as HAVE_ACPI_APEI isn't
defined, until https://lkml.org/lkml/2016/8/10/231 gets merged.
I don't think this should go to stable.
I also took the opportunity to remove some unnecessarily ifdef'd
includes.
arch/arm64/kernel/acpi.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 252a6d9c1da5..985f721f3bdd 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/cpumask.h>
+#include <linux/efi.h>
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/irqdomain.h>
@@ -28,13 +29,9 @@
#include <asm/cputype.h>
#include <asm/cpu_ops.h>
+#include <asm/pgtable.h>
#include <asm/smp_plat.h>
-#ifdef CONFIG_ACPI_APEI
-# include <linux/efi.h>
-# include <asm/pgtable.h>
-#endif
-
int acpi_noirq = 1; /* skip ACPI IRQ initialization */
int acpi_disabled = 1;
EXPORT_SYMBOL(acpi_disabled);
@@ -241,22 +238,13 @@ void __init acpi_boot_table_init(void)
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
{
/*
- * According to "Table 8 Map: EFI memory types to AArch64 memory
- * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
- * mapped to a corresponding MAIR attribute encoding.
- * The EFI memory attribute advises all possible capabilities
- * of a memory region. We use the most efficient capability.
+ * The EFI memmap isn't mapped, instead read the version exported
+ * into memblock. EFI's reserve_regions() call adds memory with the
+ * WB attribute to memblock via early_init_dt_add_memory_arch().
*/
+ if (!memblock_is_memory(addr))
+ return __pgprot(PROT_DEVICE_nGnRnE);
- u64 attr;
-
- attr = efi_mem_attributes(addr);
- if (attr & EFI_MEMORY_WB)
- return PAGE_KERNEL;
- if (attr & EFI_MEMORY_WT)
- return __pgprot(PROT_NORMAL_WT);
- if (attr & EFI_MEMORY_WC)
- return __pgprot(PROT_NORMAL_NC);
- return __pgprot(PROT_DEVICE_nGnRnE);
+ return PAGE_KERNEL;
}
#endif
--
2.10.1
^ permalink raw reply related
* [PATCH 1/1] pinctrl: st: st_pctl_dt_parse_groups simplify expression
From: Linus Walleij @ 2016-11-08 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105143515.4668-1-xypron.glpk@gmx.de>
On Sat, Nov 5, 2016 at 3:35 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> for_each_property_of_node(pins, pp) checks that pp is not NULL.
> So there is no need to check it inside the loop.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Patch applied with Patrice's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Jean-Francois Moine @ 2016-11-08 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107200505.g76zz7adtfy4ltku@lukather>
On Mon, 7 Nov 2016 21:05:05 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > >
> > > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > > > ---
> > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > - it handles the H3
> > >
> > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > the newer SoCs.
> >
> > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > regmap.
> > Many H3 registers are common with the A10, but some of them have more
> > or less fields, the fields may be at different offsets. And, finally,
> > some registers are completely different.
> > This would not raise any problem, except with regmap which is really
> > painful.
>
> That's weird, because regmap's regmap_field should make that much
> easier.
#define field_relaxed(addr, mask, val) \
writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
> > As I may understood, regmap is used to simplify suspend/resume, but, is
> > it useful to save the I2S register on suspend?
> > Practically, I am streaming some tune on my device. I suspend it for
> > any reason. The next morning, I resume it. Are you sure I want to
> > continue to hear the end of the tune?
> >
> > I better think that streaming should be simply stopped on suspend.
>
> You're mistaken. The code in there is for *runtime* suspend, ie when
> the device is no longer used, so that case shouldn't even happen at
> all.
>
> (And real suspend isn't supported anyway)
Is it time to remove this useless code?
> > Then, there is no need to save the playing registers, and, here I am,
> > there is no need to use regmap.
> >
> > May I go this way?
>
> No, please don't. regmap is also providing very useful features, such
> as access to all the registers through debugfs, or tracing. What
> exactly feels painful to you?
When the I/O registers are in memory (that's the case), you may access
them (read and write) thru /dev/mem.
Also, is a register access trace really needed in this driver?
The pain is to define the regmap_config (which registers can be
read/write/volatile and which can be the values the u-boot let us in
the registers at startup time), and the lot of code which is run instead
of simple load/store machine instructions.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Thierry Reding @ 2016-11-08 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58046fbb-8e19-e629-770a-940a40ca6ef9@nvidia.com>
On Tue, Nov 08, 2016 at 09:47:42AM +0000, Jon Hunter wrote:
>
> On 08/11/16 08:54, Peter De Schrijver wrote:
> > On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
> >>
> >> On 07/11/16 13:28, Thierry Reding wrote:
> >>> * PGP Signed by an unknown key
> >>>
> >>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
> >>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
> >>>> no OTG-enabled connector.
> >>>>
> >>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >>>> ---
> >>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> Where is this information coming from? I don't have one of the Nyans
> >>> myself, but one of the Tegra132 devices I have, which I think was
> >>> derived from one of the Nyans uses one of the external host ports as
> >>> forced recovery port, for which it would need OTG.
> >>>
> >>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> >>> In that case I think one of the ports must be OTG.
> >>
> >> It is true that the port on the back on the nyan-big can be used with
> >> recovery mode. I was thinking that this is not a true OTG port as it is
> >> just a 4-pin type A socket and does not have an ID pin. Thinking some
> >> more about this the USB spec does include a "Host Negotiation Protocol
> >> (HNP)" that allows a host and device to swap roles and so keeping it as
> >> OTG seems valid afterall.
> >
> > I don't think the bootrom implements that though. I expect recovery mode
> > to just program the controller in device mode, without performing any
> > negotiation.
>
> I am not talking about the bootrom and I would not expect the bootrom to
> do that. However, the kernel could.
Either way, configuring the controller in device mode is enough to make
the host detect it, otherwise tegrarcm wouldn't work.
>From the point of view of the binding I think "otg" is the most accurate
option because we know that the controller can operate in both modes. If
it currently doesn't or how exactly switching modes is done is outside
the scope of this property.
Is everyone okay with just dropping this patch?
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/20161108/a45c4288/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-08 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108110735.GA13098@ulmo.ba.sec>
On 08/11/16 11:07, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Nov 08, 2016 at 09:47:42AM +0000, Jon Hunter wrote:
>>
>> On 08/11/16 08:54, Peter De Schrijver wrote:
>>> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>>>>
>>>> On 07/11/16 13:28, Thierry Reding wrote:
>>>>>> Old Signed by an unknown key
>>>>>
>>>>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>>>>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>>>>>> no OTG-enabled connector.
>>>>>>
>>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>>>> ---
>>>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> Where is this information coming from? I don't have one of the Nyans
>>>>> myself, but one of the Tegra132 devices I have, which I think was
>>>>> derived from one of the Nyans uses one of the external host ports as
>>>>> forced recovery port, for which it would need OTG.
>>>>>
>>>>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
>>>>> In that case I think one of the ports must be OTG.
>>>>
>>>> It is true that the port on the back on the nyan-big can be used with
>>>> recovery mode. I was thinking that this is not a true OTG port as it is
>>>> just a 4-pin type A socket and does not have an ID pin. Thinking some
>>>> more about this the USB spec does include a "Host Negotiation Protocol
>>>> (HNP)" that allows a host and device to swap roles and so keeping it as
>>>> OTG seems valid afterall.
>>>
>>> I don't think the bootrom implements that though. I expect recovery mode
>>> to just program the controller in device mode, without performing any
>>> negotiation.
>>
>> I am not talking about the bootrom and I would not expect the bootrom to
>> do that. However, the kernel could.
>
> Either way, configuring the controller in device mode is enough to make
> the host detect it, otherwise tegrarcm wouldn't work.
>
> From the point of view of the binding I think "otg" is the most accurate
> option because we know that the controller can operate in both modes. If
> it currently doesn't or how exactly switching modes is done is outside
> the scope of this property.
>
> Is everyone okay with just dropping this patch?
Fine with me.
Jon
--
nvpublic
^ permalink raw reply
* [RESPIN-PATCH v2 0/2] Remove static mapping of SCU from mach-exynos
From: Pankaj Dubey @ 2016-11-08 11:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is part of patch series [1], which adds support of SCU
device node for Cortex-A9 based Exynos4 SoC. First two patches of the same
has been accepted and hence not included them in v2.
This patch series does some cleanup for Exynos4 SoC based boards.
We are currently statically mapping SCU SFRs in mach-exynos/exynos.c
which can be avoided if map this from device node of SCU
[1]: https://www.spinics.net/lists/arm-kernel/msg540498.html
This patch series is prepared on Krzysztof's for-next
(SHA_ID: b33c7bb9d59c3f4100d4)
I have tested these patches on Exynos4210 based on Origen board for SMP boot.
Patchset v1 was tested by Marek Szyprowski on Exynos4412-based Odroid U3
for SMP boot and S2R.
To confirm concern raised by Alim, I intentionally removed SCU device node
from exynos4.dtsi and tested on Origen board, I can see code handles this
case gracefully without any crash and system boot was fine. Of-course in such
case only single core will be able to boot.
Following boot message observed on Origen in case of missing SCU node
-------------
[ 0.000864] CPU: Testing write buffer coherency: ok
[ 0.001068] CPU0: thread -1, cpu 0, socket 9, mpidr 80000900
[ 0.001456] exynos_scu_enable failed to map scu_base
[ 0.001477] Setting up static identity map for 0x40100000 - 0x40100058
[ 1.120003] CPU1: failed to come online
[ 1.120059] Brought up 1 CPUs
[ 1.120068] SMP: Total of 1 processors activated (48.00 BogoMIPS).
[ 1.120076] CPU: All CPU(s) started in SVC mode.
-------------
Changes since v1:
- Address review comments from Krzysztof
- Moved scu_enable from pm.c and suspend.c to single place in platsmp.c
- Added error handling during scu_enable in platsmp.c
- Added Reviewed-by tag from Alim.
Pankaj Dubey (2):
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
arch/arm/mach-exynos/common.h | 6 +----
arch/arm/mach-exynos/exynos.c | 22 ------------------
arch/arm/mach-exynos/include/mach/map.h | 2 --
arch/arm/mach-exynos/platsmp.c | 34 +++++++++++++++++++++-------
arch/arm/mach-exynos/pm.c | 5 ++--
arch/arm/mach-exynos/suspend.c | 13 ++++-------
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
7 files changed, 34 insertions(+), 52 deletions(-)
--
2.7.4
^ 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