* Add Allwinner Q8 tablets hardware manager
From: Hans de Goede @ 2016-10-27 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9B288597-7812-459D-A5C7-B61107751DA6@konsulko.com>
Hi,
On 27-10-16 17:52, Pantelis Antoniou wrote:
> Hi Hans,
<snip>
>> Right, so again I think we need to split the discussion in 2 steps:
>>
>> 1) How do we apply the fixups, currently I'm using free-form changes
>> done from C-code. I can envision moving to something like the quirk
>> mechanism suggested by Pantelis in the past. Note this is not a perfect
>> fit for my rather corner-case use-case, but I can understand that in
>> general you want the variants to be described in dt, and activated
>> in some way, rather then have c-code make free-form changes to the dt
>>
>
> We?ve had this discussion before, so I guess here it goes again.
>
> I think the biggest objection is the programmatic way of applying
> every quirk by ?hand?.
>
> If there was a way to keep the probing mechanism but just spit out
> a ?model? number we could reasonably map it to an overlay to apply
> with a generic overlay manager.
>
> From an internal s/w standpoint having an expansion board or soldered
> parts makes no difference.
I disagree, with soldered parts it often is the board has
one of "accelerometer a", "b" or "c", where in the simple case
my suggested i2c-probe-stop-at-first-match property will
just work for a new board by creating a new dtb without needing any
kernel changes, where as your suggested model-string generator
C-code module would need updating.
I think that there is a need for both really.
>> 2) How do we select which fixups to apply. Again I can understand
>> you wanting some well defined mechanism for this, but again my
>> use-case is special and simply does not allow for this as there
>> is no id-eeprom to read or some such.
>>
>
> Yes there is no EEPROM but you might be able to map probing results to
> a fake ?model? number.
>
> Let me expand a bit:
>
> Assume that you have a number of probing steps, for example A, B, C each
> returning true or false, and C being executed only when B is ?true? you
> could do this to generate a bit field that identifies it.
>
> For example let?s assume that model FOO?s probing steps are
>
> A false, B true, C false -> 010
>
> Model?s BAR
>
> A true, B false, C don?t care -> 10x
>
> Mapping these to models could be
>
> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>
> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
Interesting this is actually the same direction my thoughts on this
lead me in my reply in the other thread on this started by
Antoine Tenart.
Only difference is that I suggested putting the model-string
generation in the bootloader, so it will just be there when the kernel
boots. But I agree that given things like upgradability having
the model-string generation code in the kernel is better.
<snip>
Regards,
Hans
^ permalink raw reply
* [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Jon Mason @ 2016-10-27 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eff0c717-ec4b-1dce-992a-ad5e958800f5@gmail.com>
On Wed, Oct 26, 2016 at 02:50:39PM -0700, Florian Fainelli wrote:
> On 10/26/2016 12:36 PM, Jon Mason wrote:
> > Add support for the variant of amac hardware present in the Broadcom
> > Northstar2 based SoCs. Northstar2 requires an additional register to be
> > configured with the port speed/duplexity (NICPM). This can be added to
> > the link callback to hide it from the instances that do not use this.
> > Also, the bgmac_chip_reset() was intentionally removed to prevent the
> > resetting of the chip to the default values on open. Finally, clearing
> > of the pending interrupts on init is required due to observed issues on
> > some platforms.
> >
> > Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> > ---
>
> > +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> > +{
> > + struct bgmac *bgmac = netdev_priv(net_dev);
> > + u32 val;
> > +
> > + if (!bgmac->plat.nicpm_base)
> > + return;
> > +
> > + val = NICPM_IOMUX_CTRL_INIT_VAL;
> > + switch (bgmac->net_dev->phydev->speed) {
> > + default:
> > + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> > + case SPEED_1000:
> > + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + case SPEED_100:
> > + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + case SPEED_10:
> > + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> > + break;
> > + }
> > +
> > + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> > +
> > + usleep_range(10, 100);
>
> Does not seem like a good idea, do you need that sleep?
Oops, that's not supposed to be there. Removed.
> > +
> > + bgmac_adjust_link(bgmac->net_dev);
> > +}
> > +
> > static int platform_phy_connect(struct bgmac *bgmac)
> > {
> > struct phy_device *phy_dev;
> >
> > - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> > - bgmac_adjust_link);
> > + if (bgmac->plat.nicpm_base)
> > + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> > + bgmac->dev->of_node,
> > + bgmac_nicpm_speed_set);
> > + else
> > + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> > + bgmac->dev->of_node,
> > + bgmac_adjust_link);
> > if (!phy_dev) {
> > dev_err(bgmac->dev, "Phy connect failed\n");
> > return -ENODEV;
> > }
> >
> > + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> > + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> > +
> > return 0;
> > }
> >
> > @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, bgmac);
> >
> > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> > + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> > +
> > /* Set the features of the 4707 family */
> > bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> > bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> > @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> > if (IS_ERR(bgmac->plat.idm_base))
> > return PTR_ERR(bgmac->plat.idm_base);
> >
> > + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> > + if (regs) {
> > + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> > + regs);
> > + if (IS_ERR(bgmac->plat.nicpm_base))
> > + return PTR_ERR(bgmac->plat.nicpm_base);
> > + }
> > +
> > bgmac->read = platform_bgmac_read;
> > bgmac->write = platform_bgmac_write;
> > bgmac->idm_read = platform_bgmac_idm_read;
> > @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> > static const struct of_device_id bgmac_of_enet_match[] = {
> > {.compatible = "brcm,amac",},
> > {.compatible = "brcm,nsp-amac",},
> > + {.compatible = "brcm,ns2-amac",},
> > {},
> > };
> >
> > diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> > index 38876ec..1796208 100644
> > --- a/drivers/net/ethernet/broadcom/bgmac.c
> > +++ b/drivers/net/ethernet/broadcom/bgmac.c
> > @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> > /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> > static void bgmac_chip_init(struct bgmac *bgmac)
> > {
> > + /* Clear any erroneously pending interrupts */
> > + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> > +
> > /* 1 interrupt per received frame */
> > bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
> >
> > @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> > struct bgmac *bgmac = netdev_priv(net_dev);
> > int err = 0;
> >
> > - bgmac_chip_reset(bgmac);
> > -
>
> Is this removal intentional? Maybe it should be special cased with
> checking for a NS2 BGMAC instance and not do it in that case?
The reset seems completely unnecessary. There is already 2 resets in
the probe routine, another reset serves no purpose. I can add it
back, as it does not seem to have the negative effect I was seeing
before.
Of course, if I remove this one I should remove the reset in the close
too (which seems even more unnecessary, but I didn't remove it).
Thanks,
Jon
> --
> Florian
^ permalink raw reply
* [RFC PATCH 0/5] Add an overlay manager to handle board capes
From: Hans de Goede @ 2016-10-27 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKTMjj0x6Zq3t5GsWvAC1qN10r333v9uGXkJq_DjioRmA@mail.gmail.com>
Hi,
On 27-10-16 19:30, Rob Herring wrote:
> On Thu, Oct 27, 2016 at 10:13 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 27-10-16 15:41, Rob Herring wrote:
>>>
>>> Please Cc the maintainers of drivers/of/.
>>>
>>> + Frank R, Hans, Dmitry S
>>>
>>> On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart
>>> <antoine.tenart@free-electrons.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Many boards now come with dips and compatible capes; among others the
>>>> C.H.I.P, or Beaglebones. All these boards have a kernel implementing an
>>>> out-of-tree "cape manager" which is used to detected capes, retrieve
>>>> their description and apply a corresponding overlay. This series is an
>>>> attempt to start a discussion, with an implementation of such a manager
>>>> which is somehow generic (i.e. formats or cape detectors can be added).
>>>> Other use cases could make use of this manager to dynamically load dt
>>>> overlays based on some input / hw presence.
>>>
>>>
>>> I'd like to see an input source be the kernel command line and/or a DT
>>> chosen property. Another overlay manager was proposed not to long
>>> ago[1] as well. There's also the Allwinner tablet use case from Hans
>>> where i2c devices are probed and detected. That's not using overlays
>>> currently, but maybe could.
>>
>>
>> Actually I'm currently thinking in a different direction, which I
>> think will be good for the boards where some ICs are frequently
>> replaced by 2nd (and 3th and 4th) sources, rather then that we're
>> dealing with an extension connector with capes / daughter boards.
>>
>> Although there is some overlap I'm starting to think that we need to
>> treat these 2 cases differently. Let me quickly copy and paste
>> the basic idea I've for the 2nd source touchscreen / accelerometer
>> chip case:
>>
>> """
>> The kernel actually already has a detect() method in struct i2c_driver,
>> we could use that (we would need to implement it in drivers which do not
>> have it yet). Note on second thought it seems it may be better to use
>> probe() for this, see below.
>>
>> Then we could have something like this in dt:
>>
>> &i2c0 {
>> touchscreen1: gsl1680 at 40 {
>> reg = <0x40>;
>> compatible = "silead,gsl1680";
>> enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
>> status = "disabled";
>> };
>>
>> touchscreen2: ektf2127 at 15 {
>> reg = <0x15>;
>
> Do you ever have different devices with the same address? That would
> be somewhat problematic as really these should be
> "touchscreen@<addr>".
Yes that happens (sometimes).
>
>> compatible = "elan,ektf2127";
>> enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
>> status = "disabled";
>> };
>>
>> i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>;
>> i2c-probe-stop-at-first-match-1 = <&accelerometer1>, <&accelerometer2>;
>> }
>>
>> Which would make the i2c subsys call detect (*) on each device, until
>> a device is found. Likewise we could have a "i2c-probe-all" property
>> which also walks a list of phandles but does not stop on the first
>> match.
>>
>> ...
>>
>> *) Yes this sounds Linux specific, but it really is just "execute
>> to-be-probed
>> device compatible specific detection method"
>> """
>
> Yeah, not a fan of these properties at first glance. Why can't you
> just fail probe on the non-existent devices?
That is possible and in the other thread on this there are some
links to some boards which actually already do this, but from a dt
pov it feels wrong. If we know only one of a set of options will
ever be there we ought to describe things like this in the dt.
Functionality wise this has 2 advantages:
1) We stop probing needlessly once a device is found, in some
cases the majority of the board variants has dev a, and some
have dev b / c. Then putting a first in the to-probe list will
save probing b / c on most boards.
2) Not all i2c chips are easily identifiable, so in some cases
one may want to put dev x as last to probe, because the
probe solely consists of: "Does something ack i2c transfers
at this address".
>> This does not 100% solve all q8 issues (see the "Add Allwinner Q8 tablets
>> hardware manager" thread), but does solve quite a bit of the use-case
>> and this matches what many vendor os-images (typically android) are
>> actually doing for these kind of boards.
>
> BTW, I've been meaning to ask you if you are looking at the Android
> side of things as well?
No, I purely use android os images / SDKs as a source of how the
hw works, I do not have any intentions to try and get android up
and running with mainline on these boards.
>> As for the bits this does not solve, those are mostly board specific details
>> which cannot be probed at all, and on x86 are typically solved in the device
>> driver by doing a dmi check to identify the board and then apply a board
>> specific workaround in the driver.
>>
>> I've come to believe that we should similarly delegate dealing this to
>> device
>> drivers in the devicetree case. Note that dt should still of course fully
>> describe the hardware for normal hardware, the driver would just need to
>> care
>> about weird board quirks in certain exceptions.
>
> Which is fine IMO, though I do think we should look at those cases
> carefully to ensure they stay the exception.
Ack.
>> A more interesting problem here is that dt does not have something like
>> DMI, there is the machine compatible, but that typically does not contain
>> board revision info (where as DMI often does). I believe that this is
>> actually something which should be fixed at the bootloader level
>> have it prepend a new machine compatible which contains revision info.
>>
>> Hmm, if we make the bootloader prepend a new machine compatible which
>> contains
>> revision info, we could then trigger quirks on this and in some cases avoid
>> the need for dealing with board quirks in the driver ...
>
> That would work. Board and chip versions both need better handling in
> kernel IMO.
>
> QCom has a whole scheme around version numbering in compatible
> strings. (Unfortunately, bootloaders only support their previous way
> of doing things.)
>
>> Note this is all very specific to dealing with board (revision) variants,
>> for add-ons having the bootloader add info to the machine compatible does
>> not seem the right solution.
>
> Agreed.
Regards,
Hans
^ permalink raw reply
* [PATCH next 2/2] media: mtk-mdp: NULL-terminate mtk_mdp_comp_dt_ids
From: Vincent Stehlé @ 2016-10-27 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027202325.20680-1-vincent.stehle@laposte.net>
The mtk_mdp_comp_dt_ids[] array should be NULL-terminated; add therefore an
empty entry in the end.
Fixes: c8eb2d7e8202fd9c ("[media] media: Add Mediatek MDP Driver")
Signed-off-by: Vincent Stehl? <vincent.stehle@laposte.net>
Cc: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 40a229d..53296e2 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -50,7 +50,8 @@ static const struct of_device_id mtk_mdp_comp_dt_ids[] = {
}, {
.compatible = "mediatek,mt8173-mdp-wrot",
.data = (void *)MTK_MDP_WROT
- }
+ },
+ { },
};
static const struct of_device_id mtk_mdp_of_ids[] = {
--
2.9.3
^ permalink raw reply related
* [PATCH next 1/2] media: mtk-mdp: fix video_device_release argument
From: Vincent Stehlé @ 2016-10-27 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473340146-6598-4-git-send-email-minghsiu.tsai@mediatek.com>
video_device_release() takes a pointer to struct video_device as argument.
Fix two call sites where the address of the pointer is passed instead.
Fixes: c8eb2d7e8202fd9c ("[media] media: Add Mediatek MDP Driver")
Signed-off-by: Vincent Stehl? <vincent.stehle@laposte.net>
Cc: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 9a747e7..4a9e3e9d 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -1267,13 +1267,13 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
err_m2m_init:
- video_device_release(&mdp->vdev);
+ video_device_release(mdp->vdev);
return ret;
}
void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
{
- video_device_release(&mdp->vdev);
+ video_device_release(mdp->vdev);
v4l2_m2m_release(mdp->m2m_dev);
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
From: John Stultz @ 2016-10-27 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtB0FtGbm4C5z+LJizrsHikKt_BGFti5XY+LN3w7zO1Vjw@mail.gmail.com>
On Thu, Oct 27, 2016 at 6:56 AM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> My hikey board failed to detect and mount sdcard with v4.9-rc1 and i
> have bisected the issue to this patch. Once reverted, the sdcard is
> detected again.
Hrm.. I've not seen this w/ my v4.9-rc2 based tree, and I don't have
any mmc patches there.
Can you send me your .config and point me to any other patches you're
running with? Also do you have any details about the card in case its
card specific?
Guodong: Is there any bootloader dependency on that change?
thanks
-john
^ permalink raw reply
* [alsa-devel] [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-10-27 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027171325.d68baa5ff51da4921ff8b94d@free.fr>
On Thu, Oct 27, 2016 at 05:13:25PM +0200, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 14:34:49 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens@csie.org> wrote:
> > >
> > > > > 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.
> > > >
> > > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > > > by the CODECs)
> > > >
> > > > I think this is wrong. I2S is only the DAI. You typically have a separate
> > > > platform driver for the whole card, or just use simple-card.
> > >
> > > An other device is not needed. The layout is simple:
> > > I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > > so, it cannot be the card device.
> > > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > > natural to use it to handle the card.
> >
> > Still, duplicating the driver is not the solution. I agree with
> > Chen-Yu that we want to leverage the driver that is already there.
>
> Hi Maxime and Chen-Yu,
>
> After looking at the sun4i-i2s, I found 2 solutions for re-using its
> code in the DE2 HDMI context:
>
> 1) either to split the sun4i-i2s driver into common I/O functions and
> slave CPU DAI,
>
> 2) or to move the sun4i-i2s into a master CPU DAI.
>
> (
> some explanation about 'master' and 'slave': the master is the
> component the device of which is also the sound card.
> As the sound card uses the 'drvdata' of the device, this drvdata pointer
> cannot be used by the master.
> In the actual implementations:
> - sun4i-i2s
> master: card dev = codec dev, drvdata -> card
> slave: i2s dev (CPU DAI), drvdata -> i2s data
> - sun8i-i2s
> master: card dev = i2s dev (CPU DAI), drvdata -> card
> slave: codec dev (hdmi), drvdata -> codec data (audio/video)
> )
>
> In the case 1, there is no functional change, just a source split.
> The sun8i-i2s will then use the common I/O functions.
>
> In the case 2, the CODECs using the sun4i-i2s would have to move to
> slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
> In the 4.9, there is only one codec (sun4i-codec), so, the change
> is just to move the card creation and the use of drvdata in both
> codes.
I think you're mistaken. sun4i-codec has nothing to do with the I2S
driver. It's a driver for the (poorly named) Allwinner's Audio Codec
which features it's own DAI and Codec directly into the SoC.
The DAI being different from the I2S one.
However, we want to use any codec driver with the i2s driver,
including those in sound/soc/codecs, and we already have drivers for
them.
So I'm not sure either solution is a good one. Why not just make the
HDMI part a codec itself, and use the i2s driver as the CPU DAI, like
any other codec?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20161027/7681c7e9/attachment.sig>
^ permalink raw reply
* [PATCHv2 4/4] ARM: socfpga: dts: Add Monitor to A10-SR MFD
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Monitor functionality to the Arria10 DevKit
System Resource chip.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change from -mon to -monitor for clarity.
---
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
index eb00ae3..61a5f42 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk.dtsi
@@ -121,6 +121,10 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ a10sr_monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCHv2 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Altera Arria10 DevKit System Resource Monitor functionality
to the MFD device.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change from -mon to -monitor for clarity
---
drivers/mfd/altera-a10sr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
index 06e1f7f..30de652 100644
--- a/drivers/mfd/altera-a10sr.c
+++ b/drivers/mfd/altera-a10sr.c
@@ -33,6 +33,10 @@
.name = "altr_a10sr_gpio",
.of_compatible = "altr,a10sr-gpio",
},
+ {
+ .name = "altr_a10sr_monitor",
+ .of_compatible = "altr,a10sr-monitor",
+ },
};
static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
--
1.9.1
^ permalink raw reply related
* [PATCHv2 2/4] misc: Add Altera Arria10 System Resource Control
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
This patch adds the Altera Arria10 control & monitoring
functions to the Arria10 System Resource chip.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
v2 Change compatible string and filename from -mon to -monitor
Change CONFIG from module to builtin.
Make wm_rst register writeable.
---
MAINTAINERS | 1 +
drivers/misc/Kconfig | 7 ++
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 176 ++++++++++++++++++++++++++++++++++++
4 files changed, 185 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 813ea85..1c5b0be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -631,6 +631,7 @@ M: Thor Thayer <tthayer@opensource.altera.com>
S: Maintained
F: drivers/gpio/gpio-altera-a10sr.c
F: drivers/mfd/altera-a10sr.c
+F: drivers/misc/altera-a10sr-monitor.c
F: include/linux/mfd/altera-a10sr.h
ALTERA TRIPLE SPEED ETHERNET DRIVER
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 64971ba..f42d459 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -766,6 +766,13 @@ config PANEL_BOOT_MESSAGE
An empty message will only clear the display at driver init time. Any other
printf()-formatted message is valid with newline and escape codes.
+config ALTERA_A10SR_MONITOR
+ bool "Altera Arria10 System Resource Monitor"
+ depends on MFD_ALTERA_A10SR
+ help
+ This enables the System Resource monitor driver for the Altera
+ Arria10 DevKit.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3198336..9f6e77a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -43,6 +43,7 @@ obj-y += ti-st/
obj-y += lis3lv02d/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
+obj-$(CONFIG_ALTERA_A10SR_MONITOR) += altera-a10sr-monitor.o
obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
diff --git a/drivers/misc/altera-a10sr-monitor.c b/drivers/misc/altera-a10sr-monitor.c
new file mode 100644
index 0000000..838ec2c
--- /dev/null
+++ b/drivers/misc/altera-a10sr-monitor.c
@@ -0,0 +1,176 @@
+/*
+ * Altera Arria10 DevKit System Resource Chip Monitor Driver
+ *
+ * Author: Thor Thayer <tthayer@opensource.altera.com>
+ *
+ * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Monitor driver for the Altera Arria10 MAX5 System Resource Chip
+ * Adapted from ics932s401.c
+ */
+
+#include <linux/err.h>
+#include <linux/mfd/altera-a10sr.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct altr_a10sr_regs {
+ struct regmap *regmap;
+ struct attribute_group attr_grp;
+};
+
+static ssize_t a10sr_show(struct device *dev,
+ struct device_attribute *devattr, char *buf);
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count);
+
+/* Define FS entries */
+static DEVICE_ATTR(max5_version, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_led, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_button, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_button_irq, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pg1, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg2, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_pg3, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_fmcab, 0444, a10sr_show, NULL);
+static DEVICE_ATTR(max5_hps_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_per_resets, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpa, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_sfpb, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_i2c_master, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_wm_rst_key, 0644, a10sr_show, a10sr_store);
+static DEVICE_ATTR(max5_pmbus, 0644, a10sr_show, a10sr_store);
+
+static struct attribute *altr_a10sr_attr[] = {
+ &dev_attr_max5_version.attr,
+ &dev_attr_max5_led.attr,
+ &dev_attr_max5_button.attr,
+ &dev_attr_max5_button_irq.attr,
+ &dev_attr_max5_pg1.attr,
+ &dev_attr_max5_pg2.attr,
+ &dev_attr_max5_pg3.attr,
+ &dev_attr_max5_fmcab.attr,
+ &dev_attr_max5_hps_resets.attr,
+ &dev_attr_max5_per_resets.attr,
+ &dev_attr_max5_sfpa.attr,
+ &dev_attr_max5_sfpb.attr,
+ &dev_attr_max5_i2c_master.attr,
+ &dev_attr_max5_wm_rst.attr,
+ &dev_attr_max5_wm_rst_key.attr,
+ &dev_attr_max5_pmbus.attr,
+ NULL
+};
+
+static const struct attribute_group a10sr_attr_group = {
+ .attrs = altr_a10sr_attr,
+};
+
+static ssize_t a10sr_show(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ int i, ret;
+ unsigned int val;
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit set by regmap for Read */
+ i <<= 1;
+ ret = regmap_read(a10sr_regs->regmap, i, &val);
+ if (ret < 0)
+ return ret;
+
+ return sprintf(buf, "0x%X\n", val);
+}
+
+static ssize_t a10sr_store(struct device *dev,
+ struct device_attribute *devattr, const char *buf,
+ size_t count)
+{
+ struct altr_a10sr_regs *a10sr_regs = dev_get_drvdata(dev);
+ unsigned long val;
+ int i, ret;
+
+ ret = kstrtol(buf, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(altr_a10sr_attr); i++) {
+ if (devattr == (struct device_attribute *)altr_a10sr_attr[i])
+ break;
+ }
+ if (i >= ARRAY_SIZE(altr_a10sr_attr))
+ return -EINVAL;
+
+ /* Shift because LS bit cleared by regmap for Write */
+ i <<= 1;
+ ret = regmap_write(a10sr_regs->regmap, i, val);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static int altr_a10sr_regs_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct altr_a10sr_regs *a10regs;
+ struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
+
+ a10regs = devm_kzalloc(&pdev->dev, sizeof(*a10regs), GFP_KERNEL);
+ if (!a10regs)
+ return -ENOMEM;
+
+ a10regs->regmap = a10sr->regmap;
+ a10regs->attr_grp = a10sr_attr_group;
+
+ platform_set_drvdata(pdev, a10regs);
+
+ return sysfs_create_group(&pdev->dev.kobj, &a10sr_attr_group);
+}
+
+static int altr_a10sr_regs_remove(struct platform_device *pdev)
+{
+ struct altr_a10sr_regs *a10regs = platform_get_drvdata(pdev);
+
+ sysfs_remove_group(&pdev->dev.kobj, &a10regs->attr_grp);
+
+ return 0;
+}
+
+static const struct of_device_id altr_a10sr_regs_of_match[] = {
+ { .compatible = "altr,a10sr-monitor" },
+ { },
+};
+
+static struct platform_driver altr_a10sr_regs_driver = {
+ .probe = altr_a10sr_regs_probe,
+ .remove = altr_a10sr_regs_remove,
+ .driver = {
+ .name = "altr_a10sr_monitor",
+ .of_match_table = altr_a10sr_regs_of_match,
+ },
+};
+
+builtin_platform_driver(altr_a10sr_regs_driver);
--
1.9.1
^ permalink raw reply related
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477598426-28125-1-git-send-email-tthayer@opensource.altera.com>
From: Thor Thayer <tthayer@opensource.altera.com>
Add the Arria10 DevKit System Resource Chip register and state
monitoring module to the MFD.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
---
Note: This needs to be applied to the bindings document that
was Acked & Applied but didn't reach the for-next branch.
See https://patchwork.ozlabs.org/patch/629397/
---
v2 Change compatible string -mon to -monitor for clarity
---
Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
index ea151f2..c47be28 100644
--- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
+++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
@@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
Device Description
------ ----------
a10sr_gpio GPIO Controller
+a10sr_monitor Register and State Monitoring
Arria10 GPIO
Required Properties:
@@ -27,6 +28,10 @@ Required Properties:
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+Arria10 Register and State Monitor
+Required Properties:
+- compatible : Should be "altr,a10sr-monitor"
+
Example:
resource-manager at 0 {
@@ -43,4 +48,8 @@ Example:
gpio-controller;
#gpio-cells = <2>;
};
+
+ a10sr_monitor {
+ compatible = "altr,a10sr-monitor";
+ };
};
--
1.9.1
^ permalink raw reply related
* [PATCHv2 0/4] Add Altera A10SR Status & Control Monitor
From: tthayer at opensource.altera.com @ 2016-10-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <tthayer@opensource.altera.com>
This patch series adds the Altera Arria10 DevKit System Resource
chip's Status and Control Monitor to the A10SR Multi-Function
Device. An earlier patch added this to the hwmon class which
wasn't the proper place so this functionality is added to the
misc directory.
Version 2 changes the DT names from -mon to -monitor for better
readability and clarity and changed the previous version from
modular to built-in.
Thor Thayer (4):
dt-bindings: mfd: Add Altera Arria10 SR Monitor
misc: Add Altera Arria10 System Resource Control
mfd: altr-a10sr: Add Arria10 SR Monitor
ARM: socfpga: dts: Add Monitor to A10-SR MFD
.../devicetree/bindings/mfd/altera-a10sr.txt | 9 ++
MAINTAINERS | 1 +
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 +
drivers/mfd/altera-a10sr.c | 4 +
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 176 +++++++++++++++++++++
7 files changed, 202 insertions(+)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
--
1.9.1
^ permalink raw reply
* [PATCH 7/9] Input: wm97xx: split out touchscreen registering
From: Robert Jarzmik @ 2016-10-27 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027090233.GF28180@localhost.localdomain>
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> writes:
> On Wed, Oct 26, 2016 at 09:41:45PM +0200, Robert Jarzmik wrote:
>> diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c
>> index 83cf11312fd9..50a110e2988b 100644
> <snip>
>> +static void wm97xx_remove_battery(struct wm97xx *wm)
>> +{
>> + platform_device_put(wm->battery_dev);
>> +}
> <snip>
>> @@ -724,10 +757,8 @@ static int wm97xx_remove(struct device *dev)
>> {
>> struct wm97xx *wm = dev_get_drvdata(dev);
>>
>> - platform_device_unregister(wm->battery_dev);
>> - platform_device_unregister(wm->touch_dev);
>> - input_unregister_device(wm->input_dev);
>> - kfree(wm);
>> + wm97xx_remove_battery(wm);
>
> The commit message says this is just shifting code around but the
> platform_device_unregister for the battery_dev seems to have
> turned into a platform_device_put here.
Thanks for spotting that, it's clearly a defect in the patch.
That implies a v2 at least for this one.
Cheers.
--
Robert
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Pantelis Antoniou @ 2016-10-27 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjS_=k4qE25t2b9eNnuqvVHf-1g7CZr81pPJx==aftF4xw@mail.gmail.com>
Hi Pierre,
> On Oct 27, 2016, at 22:04 , Pierre-Hugues Husson <phh@phh.me> wrote:
>
> 2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>>
>> Hi Pierre,
>>
>>> On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh@phh.me> wrote:
>>>
>>> 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>>>> Yes there is no EEPROM but you might be able to map probing results to
>>>> a fake ?model? number.
>>>>
>>>> Let me expand a bit:
>>>>
>>>> Assume that you have a number of probing steps, for example A, B, C each
>>>> returning true or false, and C being executed only when B is ?true? you
>>>> could do this to generate a bit field that identifies it.
>>>>
>>>> For example let?s assume that model FOO?s probing steps are
>>>>
>>>> A false, B true, C false -> 010
>>>>
>>>> Model?s BAR
>>>>
>>>> A true, B false, C don?t care -> 10x
>>>>
>>>> Mapping these to models could be
>>>>
>>>> Model FOO, (010 & 111) == 010 (all three probing steps must match)
>>>>
>>>> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
>>>
>>> This method looks too complex on multiple grounds.
>>> Assuming your method, I'm not too sure how this would actually be
>>> described in a DTS.
>>> Such probing steps should include reading/matching IDs in an EEPROM/on
>>> an ADC, but it should also include the result of a driver's probe.
>>> Also, drivers should have a way to report an ID/OTP instead of just a
>>> boolean.
>>>
>>
>> Err, I don?t think you got the point.
>>
>> The probing steps are done by a board specific probe driver.
>> This driver performs the probing steps (which is exactly what Hans?s
>> method now does) but instead of applying changes to the device tree
>> programmatically generates a model string.
>>
>> This model string can be used by a general purpose overlay manager to apply
>> the overlay(s) for the specific board. The plural part is important - read
>> below.
>
> Ok, I agree I didn't get the point, and I'm not sure I do now.
> If I understand correctly, the difference between your method and
> Hans', is that instead of manipulating directly OF properties based on
> heuristics, there will be a heuristic to determine model revision, and
> THEN apply overlays based on determined model revision.
>
> If this is the correct interpretation, this means that for boards with
> two possible accelerometers, a new driver is required, while something
> as simple as i2c-probe-stop-at-first-match wouldn't require a new
> driver.
>
It does require a new driver, but the driver is simple a probing method
driver; it does not require to modify the actual drivers that are going
to be instantiated.
In DT terms for a board specific probe driver:
bpm: board_probe_method {
compatible = ?foocorp,bar-board-probe?;
};
genm: generic_model_manager {
compatible = ?generic-model-manager?;
probe-method = <&bpm>;
/* list of models and overlays to apply in sequence */
models {
foo-model-0 = ?foo,bar,screen-A?, ?foo,bar,accel-A?;
foo-model-1 = ?foo,bar,screen-A?, ?foo,bar,accel-B?;
foo-model-2 = ?foo,bar,screen-B?, ?foo,bar,accel-A?;
foo-model-3 = ?foo,bar,screen-B?, ?foo,bar,accel-B?;
};
};
The manager can call the single exported method which could be as simple
as:
const char *probe_identify();
In fact for things like i2c probe a generic probe method might suffice.
i2c_generic_bpm: generic_i2c_probe_method {
compatible = ?i2c-generic-probe-method?;
models {
model at 0 {
result = ?foo-model-0?;
/* match when read at address 12 returns 5 */
/* and read at address 14 returns 0 */
/* format is command, bus, address, argument */
match = <MATCH_READ &i2c0 12 5>, <MATCH_READ &i2c0 0 14 0>;
? etc ...
};
};
};
>>> As you mentioned, it is a way to distinguish models, not just a set of
>>> parameters.
>>> Does this mean that this DT would lead to loading various DT based on
>>> the matching model, which would look like a FIT?
>>> Also there is a modularity problem there. If I have phones with either
>>> screen A or screen B, and with either accelerometer A or accelerometer
>>> B, I would have to implement all four combinations.
>>>
>>
>> The model lookup need not result in a simple overlay to apply.
>>
>> So for your case it would be:
>>
>> model corp,0 -> overlay screen A + overlay accel A
>> model corp,1 -> overlay screen A + overlay accel B
>> model corp,2 -> overlay screen B + overlay accel A
>> model corp,3 -> overlay screen B + overlay accel B
>>
>> You don?t need the combinatorial number of overlays.
>
> My worry initially was that all 4 "model corp" are needed, while with
> using a simple approach like i2c-probe-stop-at-first-match, this
> wouldn't be needed.
> But now that I'm thinking of it again, for such a case to happen, this
> would require to have OEMs picking random components for tablets of
> one production batch. This wouldn't make any sense.
> So I agree a model-based method should cover sufficient cases to be worthwhile.
> I think it covers every device I've met.
>
Yeah, model number in this case means both model and revision.
If components change you change the internal model number.
> Regards,
Regards
? Pantelis
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Pierre-Hugues Husson @ 2016-10-27 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D75CB7DE-4165-4D2F-B40B-D2B6875C0172@konsulko.com>
2016-10-27 19:11 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
>
> Hi Pierre,
>
> > On Oct 27, 2016, at 19:59 , Pierre-Hugues Husson <phh@phh.me> wrote:
> >
> > 2016-10-27 17:52 GMT+02:00 Pantelis Antoniou <pantelis.antoniou@konsulko.com>:
> >> Yes there is no EEPROM but you might be able to map probing results to
> >> a fake ?model? number.
> >>
> >> Let me expand a bit:
> >>
> >> Assume that you have a number of probing steps, for example A, B, C each
> >> returning true or false, and C being executed only when B is ?true? you
> >> could do this to generate a bit field that identifies it.
> >>
> >> For example let?s assume that model FOO?s probing steps are
> >>
> >> A false, B true, C false -> 010
> >>
> >> Model?s BAR
> >>
> >> A true, B false, C don?t care -> 10x
> >>
> >> Mapping these to models could be
> >>
> >> Model FOO, (010 & 111) == 010 (all three probing steps must match)
> >>
> >> Model BAR, (10x & 110) = 100 (the first two probing steps must match)
> >
> > This method looks too complex on multiple grounds.
> > Assuming your method, I'm not too sure how this would actually be
> > described in a DTS.
> > Such probing steps should include reading/matching IDs in an EEPROM/on
> > an ADC, but it should also include the result of a driver's probe.
> > Also, drivers should have a way to report an ID/OTP instead of just a
> > boolean.
> >
>
> Err, I don?t think you got the point.
>
> The probing steps are done by a board specific probe driver.
> This driver performs the probing steps (which is exactly what Hans?s
> method now does) but instead of applying changes to the device tree
> programmatically generates a model string.
>
> This model string can be used by a general purpose overlay manager to apply
> the overlay(s) for the specific board. The plural part is important - read
> below.
Ok, I agree I didn't get the point, and I'm not sure I do now.
If I understand correctly, the difference between your method and
Hans', is that instead of manipulating directly OF properties based on
heuristics, there will be a heuristic to determine model revision, and
THEN apply overlays based on determined model revision.
If this is the correct interpretation, this means that for boards with
two possible accelerometers, a new driver is required, while something
as simple as i2c-probe-stop-at-first-match wouldn't require a new
driver.
> > As you mentioned, it is a way to distinguish models, not just a set of
> > parameters.
> > Does this mean that this DT would lead to loading various DT based on
> > the matching model, which would look like a FIT?
> > Also there is a modularity problem there. If I have phones with either
> > screen A or screen B, and with either accelerometer A or accelerometer
> > B, I would have to implement all four combinations.
> >
>
> The model lookup need not result in a simple overlay to apply.
>
> So for your case it would be:
>
> model corp,0 -> overlay screen A + overlay accel A
> model corp,1 -> overlay screen A + overlay accel B
> model corp,2 -> overlay screen B + overlay accel A
> model corp,3 -> overlay screen B + overlay accel B
>
> You don?t need the combinatorial number of overlays.
My worry initially was that all 4 "model corp" are needed, while with
using a simple approach like i2c-probe-stop-at-first-match, this
wouldn't be needed.
But now that I'm thinking of it again, for such a case to happen, this
would require to have OEMs picking random components for tablets of
one production batch. This wouldn't make any sense.
So I agree a model-based method should cover sufficient cases to be worthwhile.
I think it covers every device I've met.
Regards,
^ permalink raw reply
* [PATCH 3/3] misc: SRAM: Add option to map SRAM to allow code execution
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Allow option for mapping SRAM as executable. DT node can specify
"memory-exec" and "memory-exec-nocache" to also map it as non-cached.
This is useful for platforms using the sram driver that need to run
PM code from sram like several ARM platforms.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
Documentation/devicetree/bindings/sram/sram.txt | 2 ++
drivers/misc/sram.c | 7 +++++++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.txt b/Documentation/devicetree/bindings/sram/sram.txt
index add48f09015e..8eac557204e5 100644
--- a/Documentation/devicetree/bindings/sram/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sram.txt
@@ -29,6 +29,8 @@ Optional properties in the sram node:
- no-memory-wc : the flag indicating, that SRAM memory region has not to
be remapped as write combining. WC is used by default.
+- memory-exec : map range to allow code execution
+- memory-exec-nocache : map range to allow code execution and also non-cached
Required properties in the area nodes:
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index f84b53d6ce50..a9ba1be115bb 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -362,6 +362,13 @@ static int sram_probe(struct platform_device *pdev)
if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
sram->virt_base = devm_ioremap(sram->dev, res->start, size);
+ else if (of_property_read_bool(pdev->dev.of_node, "memory-exec"))
+ sram->virt_base = devm_memremap(sram->dev, res->start, size,
+ MEMREMAP_EXEC);
+ else if (of_property_read_bool(pdev->dev.of_node,
+ "memory-exec-nocache"))
+ sram->virt_base = devm_memremap(sram->dev, res->start, size,
+ MEMREMAP_EXEC_NOCACHE);
else
sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
if (!sram->virt_base)
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Add flags to memremap() for MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE
mappings. Mappings provided by these flags will both allow execution,
with MEMREMAP_EXEC_NOCACHE also requiring the memory to be mapped
non-cached. These mappings are useful for architectures that must map
on-chip memory such as SRAM and then copy and execute code from it, such
as code used to reconfigure system memory controllers or the low-level PM
code on ARM platforms.
Also add stubs for both underlying arch_memremap_exec/nocache calls that
return NULL so that if either is attempted from a platform cannot map
memory in such a way will fail.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
include/linux/io.h | 2 ++
kernel/memremap.c | 34 +++++++++++++++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index e2c8419278c1..6668b6b9123b 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -136,6 +136,8 @@ enum {
MEMREMAP_WB = 1 << 0,
MEMREMAP_WT = 1 << 1,
MEMREMAP_WC = 1 << 2,
+ MEMREMAP_EXEC = 1 << 3,
+ MEMREMAP_EXEC_NOCACHE = 1 << 4,
};
void *memremap(resource_size_t offset, size_t size, unsigned long flags);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index b501e390bb34..47cefc64057d 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -34,6 +34,21 @@ static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
}
#endif
+#ifndef arch_memremap_exec
+static void *arch_memremap_exec(resource_size_t offset, unsigned long size)
+{
+ return NULL;
+}
+#endif
+
+#ifndef arch_memremap_exec_nocache
+static void *arch_memremap_exec_nocache(resource_size_t offset,
+ unsigned long size)
+{
+ return NULL;
+}
+#endif
+
static void *try_ram_remap(resource_size_t offset, size_t size)
{
unsigned long pfn = PHYS_PFN(offset);
@@ -48,7 +63,8 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
* memremap() - remap an iomem_resource as cacheable memory
* @offset: iomem resource start address
* @size: size of remap
- * @flags: any of MEMREMAP_WB, MEMREMAP_WT and MEMREMAP_WC
+ * @flags: any of MEMREMAP_WB, MEMREMAP_WT, MEMREMAP_WC, MEMREMAP_EXEC,
+ * and MEMREMAP_EXEC_NOCACHE
*
* memremap() is "ioremap" for cases where it is known that the resource
* being mapped does not have i/o side effects and the __iomem
@@ -70,6 +86,16 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
* MEMREMAP_WC - establish a writecombine mapping, whereby writes may
* be coalesced together (e.g. in the CPU's write buffers), but is otherwise
* uncached. Attempts to map System RAM with this mapping type will fail.
+ *
+ * MEMREMAP_EXEC - map memory as cached, as MEMREMAP_WB does, but also
+ * executable to allow for executing code from something like an on-chip
+ * memory. If support for executable mapping is not present on platform
+ * then the mapping will fail.
+ *
+ * MEMREMAP_EXEC_NOCACHE - map memory as non-cached and executable to allow
+ * for executing code from something like an on-chip memory. If support for
+ * executable, non-cached mapping is not present on platform then the
+ * mapping will fail.
*/
void *memremap(resource_size_t offset, size_t size, unsigned long flags)
{
@@ -118,6 +144,12 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
if (!addr && (flags & MEMREMAP_WC))
addr = ioremap_wc(offset, size);
+ if (!addr && (flags & MEMREMAP_EXEC))
+ addr = arch_memremap_exec(offset, size);
+
+ if (!addr && (flags & MEMREMAP_EXEC_NOCACHE))
+ addr = arch_memremap_exec_nocache(offset, size);
+
return addr;
}
EXPORT_SYMBOL(memremap);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] ARM: memremap: implement arch_memremap_exec/exec_nocache
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027185612.22362-1-d-gerlach@ti.com>
Introduce arch_memremap_exec and arch_memremap_exec_nocache for ARM to
allow mapping of memory as executable. Some platforms have a requirement
to map on-chip memory, such as SRAM, to hold and run code that cannot be
executed in DRAM, such as low-level PM code or code to reconfigure the
DRAM controller itself.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/include/asm/io.h | 5 +++++
arch/arm/mm/ioremap.c | 16 ++++++++++++++++
arch/arm/mm/nommu.c | 12 ++++++++++++
3 files changed, 33 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 021692c64de3..67476a5add20 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -411,6 +411,11 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
void iounmap(volatile void __iomem *iomem_cookie);
#define iounmap iounmap
+void *arch_memremap_exec(phys_addr_t phys_addr, size_t size);
+void *arch_memremap_exec_nocache(phys_addr_t phys_addr, size_t size);
+#define arch_memremap_exec arch_memremap_exec
+#define arch_memremap_exec_nocache arch_memremap_exec_nocache
+
void *arch_memremap_wb(phys_addr_t phys_addr, size_t size);
#define arch_memremap_wb arch_memremap_wb
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ff0eed23ddf1..5c22a7a0b349 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -419,6 +419,22 @@ __arm_ioremap_exec(phys_addr_t phys_addr, size_t size, bool cached)
__builtin_return_address(0));
}
+void *arch_memremap_exec(phys_addr_t phys_addr, size_t size)
+{
+ return (__force void *)arch_ioremap_caller(phys_addr, size,
+ MT_MEMORY_RWX,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap_exec);
+
+void *arch_memremap_exec_nocache(phys_addr_t phys_addr, size_t size)
+{
+ return (__force void *)arch_ioremap_caller(phys_addr, size,
+ MT_MEMORY_RWX_NONCACHED,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(arch_memremap_exec_nocache);
+
void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
{
return (__force void *)arch_ioremap_caller(phys_addr, size,
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967727e2..038922133ec4 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -390,6 +390,18 @@ void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
return (void *)phys_addr;
}
+void *arch_memremap_exec(phys_addr_t phys_addr, size_t size)
+{
+ return (void *)phys_addr;
+}
+EXPORT_SYMBOL(arch_memremap_exec);
+
+void *arch_memremap_exec_nocache(phys_addr_t phys_addr, size_t size)
+{
+ return (void *)phys_addr;
+}
+EXPORT_SYMBOL(arch_memremap_exec_nocache);
+
void __iounmap(volatile void __iomem *addr)
{
}
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] Add memremap executable mapping and extend drivers/misc/sram.c
From: Dave Gerlach @ 2016-10-27 18:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
There are several instances when one would want to execute out of on-chip
SRAM, such as PM code on ARM platforms, so once again revisiting this
series to allow that in a generic manner. Seems that having a solution for
allowing SRAM to be mapped as executable will help clean up PM code on several
ARM platforms that are using ARM internal __arm_ioremap_exec API
and also open the door for PM support on new platforms like TI AM335x and
AM437x. This was last sent as RFC here [1] and based on comments from Russell
King and Arnd Bergmann has been rewritten to use memremap API rather than
ioremap API, as executable iomem does not really make sense.
I still see several platforms (at-91, imx6, socfpga) that could make use
of this and use the generic sram driver to allocate the SRAM needed for PM.
This series allows direct allocation of SRAM using the generic SRAM driver
that will be already mapped as executable. Otherwise platform SRAM allocation
code must be used or if the generic sram driver is used as-is the memory
must be remapped as executable after it has been mapped normally by the
SRAM driver.
I had sent omap3 series to convert from using old omap sram platform
mapping code to using the generic sram driver instead here [2] which was
based on previous RFC but can easily be rebased on this updated series.
Finally, forthcoming TI am335x and am437x PM code must make use of
it as well, as portions of PM code are moving in to drivers.
Changes from the RFC include:
- Rather than introduce ioremap_exec API, use memremap API, as the concept
of executable iomem does not make sense; any memory that can used to
run code should not have io side effects like iomem.
- Rather than having a fallback mapping if a platform does not support
exec mappings under the memremap API, have the mapping fail, as if you
are mapping memory as exec, presumably you will then try to run code
from it which will fail anyway, so it makes more sense to prevent the
mapping in the first place.
- Update sram driver to use memremap rather than ioremap for exec flags.
Regards,
Dave
[1] http://www.spinics.net/lists/arm-kernel/msg503071.html
[2] http://www.spinics.net/lists/linux-omap/msg128753.html
Dave Gerlach (3):
ARM: memremap: implement arch_memremap_exec/exec_nocache
memremap: add MEMREMAP_EXEC and MEMREMAP_EXEC_NOCACHE flags
misc: SRAM: Add option to map SRAM to allow code execution
Documentation/devicetree/bindings/sram/sram.txt | 2 ++
arch/arm/include/asm/io.h | 5 ++++
arch/arm/mm/ioremap.c | 16 ++++++++++++
arch/arm/mm/nommu.c | 12 +++++++++
drivers/misc/sram.c | 7 +++++
include/linux/io.h | 2 ++
kernel/memremap.c | 34 ++++++++++++++++++++++++-
7 files changed, 77 insertions(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [PATCH V3 5/6] ARM: tegra: Add Tegra20 GMI support
From: Mirza Krak @ 2016-10-27 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201610280016.MiLeMJw9%fengguang.wu@intel.com>
2016-10-27 19:09 GMT+02:00 kbuild test robot <lkp@intel.com>:
> Hi Mirza,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.9-rc2 next-20161027]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
>
> url: https://github.com/0day-ci/linux/commits/Mirza-Krak/clk-tegra-add-TEGRA20_CLK_NOR-to-init-table/20161027-225528
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: arm-davinci_all_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 >>):
>
>>> Error: arch/arm/boot/dts/tegra20.dtsi:1.1-8 syntax error
> FATAL ERROR: Unable to parse input tree
That one was embarrassing. Sorry...
Best Regards
Mirza
^ permalink raw reply
* [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC
From: Mark Brown @ 2016-10-27 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027191634.f2fa6478cd07d84a60274339@free.fr>
On Thu, Oct 27, 2016 at 07:16:34PM +0200, Jean-Francois Moine wrote:
> Chen-Yu Tsai <wens@csie.org> wrote:
> > There's already a driver for basically the same thing:
> > sound/soc/codec/hdmi-codec.c
> > You use it by registering a sub-device from your hdmi driver, with the
> > proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
> > platforms already using it.
> I know that for a long time, and I will not use it on any account: it is
> a gasworks!
If there are problems with what's there then articulate them and fix
them, don't just open code something separate. Just open coding
something else without any articulated reasoning is not helping things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/1b274085/attachment-0001.sig>
^ permalink raw reply
* [PATCH] irq-bcm2836: Prevent spurious interrupts, and trap them early
From: Eric Anholt @ 2016-10-27 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027164051.22493-1-eric@anholt.net>
Eric Anholt <eric@anholt.net> writes:
> From: Phil Elwell <phil@raspberrypi.org>
>
> The old arch-specific IRQ macros included a dsb to ensure the
> write to clear the mailbox interrupt completed before returning
> from the interrupt. The BCM2836 irqchip driver needs the same
> precaution to avoid spurious interrupts.
>
> Spurious interrupts are still possible for other reasons,
> though, so trap them early.
>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>
> Phil, your patch didn't apply because it looks like you pasted into
> gmail (tabs got converted to spaces). git-send-email can avoid that.
> I've pulled it out of the rpi tree and applied the s-o-b from your
> email.
>
> Also, patches to lkml need to be sent to the relevant maintainers or
> they won't get picked up. ./scripts/get_maintainer.pl <patch> can
> give you the list of who to send to/cc.
And then it was my turn to fumble a patch email. Autocompleted the
wrong version(s). Resending :(
^ permalink raw reply
* [PATCH v2] irqchip/bcm2836: Prevent spurious interrupts
From: Eric Anholt @ 2016-10-27 18:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Phil Elwell <phil@raspberrypi.org>
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/irqchip/irq-bcm2836.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index d96b2c947e74..93e3f7660c42 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -175,6 +175,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
u32 ipi = ffs(mbox_val) - 1;
writel(1 << ipi, mailbox0);
+ dsb(sy);
handle_IPI(ipi, regs);
#endif
} else if (stat) {
--
2.9.3
^ permalink raw reply related
* [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Uwe Kleine-König @ 2016-10-27 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027160406.25738-1-richard.genoud@gmail.com>
Hello Richard,
On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index fd8aa1f4ba78..168b10cad47b 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> mode |= ATMEL_US_USMODE_RS485;
> } else if (termios->c_cflag & CRTSCTS) {
> /* RS232 with hardware handshake (RTS/CTS) */
> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> - termios->c_cflag &= ~CRTSCTS;
> - } else {
> + if (atmel_use_fifo(port) &&
> + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> + /*
> + * with ATMEL_US_USMODE_HWHS set, the controller will
> + * be able to drive the RTS pin high/low when the RX
> + * FIFO is above RXFTHRES/below RXFTHRES2.
> + * It will also disable the transmitter when the CTS
> + * pin is high.
> + * This mode is not activated if CTS pin is a GPIO
> + * because in this case, the transmitter is always
> + * disabled (there must be an internal pull-up
> + * responsible for this behaviour).
> + * If the RTS pin is a GPIO, the controller won't be
> + * able to drive it according to the FIFO thresholds,
> + * but it will be handled by the driver.
> + */
> mode |= ATMEL_US_USMODE_HWHS;
You use
!mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
as indicator that the cts mode of the respective pin is used. Is this
reliable? (It's not if there are machines that don't use CTS, neither as
gpio nor using the hardware function.) Maybe this needs a dt property to
indicate that there is no (hw)handshaking available?
> + } else {
> + ...
> }
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Eric Anholt @ 2016-10-27 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477505640-26658-2-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> The address of the mailbox node in the bcm283x.dts has also a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
I've marked these to be applied once Rob acks the docs change.
^ 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