* RE: [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-09 6:24 UTC (permalink / raw)
To: 'Robin Murphy', will.deacon, joro, iommu,
linux-arm-kernel, linux-arm-msm, laurent.pinchart, m.szyprowski,
tfiga, srinivas.kandagatla
In-Reply-To: <9f36244f-62d4-08e3-d64a-2b04ad4dc2e0@arm.com>
Hi Robin,
>On 04/11/16 15:16, Sricharan wrote:
>> Hi Robin,
>>
>>>>> Yikes, on second look, that definitely shouldn't be happening.
>>>>> Everything below is probably the resulting fallout.
>>>>
>>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>>>
>>>> I think the above print which says "failed to setup iommu_ops"
>>>> because the call ops->add_device failed in of_pci_iommu_configure
>>>> is the reason for the failure, in my case i simply do not get this even with
>>>> your scripts. ops->add_device succeeds in the rebind as well. So still
>>>> checking what could be happening in your case.
>>>
>>> I was looking at your code base from [1].The ops->add_device
>>> callback from of_pci_iommu_configure on the rebind is the
>>> one which is causing the failure. But not able to spot out
>>>from code which point is causing the failure. It would be very helpful
>>> if i can know which is the return value from the add_device callback
>>> or point inside add_device callback which fails in your setup.
>>>
>>>
>>> [1] git://linux-arm.org/linux-rm iommu/misc
>>
>> With little more try, i saw an issue where i had an failure
>> similar to what you reported. The issue happens when multiple
>> devices fall in to same group due to matching sids. I ended up
>> doing a fix like below and it would be nice to verify if it is the same
>> that we are seeing in your setup and if the fix makes a difference ?
>>
>> From: Sricharan R <sricharan@codeaurora.org>
>> Date: Fri, 4 Nov 2016 20:28:49 +0530
>> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>>
>> iommu_group_get_for_dev which gets called in the add_device
>> callback, increases the reference count of the iommu_group,
>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>> inturn calls device_group callback and in the case of arm-smmu
>> we call generic_device_group/pci_device_group which takes
>> care of increasing the group's reference. But when we return
>> an already existing group(when multiple devices have same group)
>> the reference is not incremented, resulting in issues when the
>> remove_device callback for the devices is invoked.
>> Fixing the same here.
>
>Bah, yes, this does look like my fault - after flip-flopping between
>about 3 different ways to keep refcounts for the S2CR entries, none of
>which would quite work, I ripped it all out but apparently still got
>things wrong, oh well. Thanks for figuring it out.
>
>On the probe-deferral angle, whilst it's useful to have uncovered this
>bug, I don't think we should actually be calling remove_device() from
>DMA teardown. I think it's preferable from a user perspective if group
>numbering remains stable, rather than changing depending on the order in
>which they unbind/rebind VFIO drivers. I'm really keen to try and get
>this in shape for 4.10, so I've taken the liberty of hacking up my own
>branch (iommu/defer) based on v3 - would you mind taking a look at the
>two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>to your later patches - that was an experiment which didn't really work out)
Ok, will take a look at this now and respond more on this.
>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 71ce4b6..a1d0b3c 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
>> group = smmu->s2crs[idx].group;
>> }
>>
>> - if (group)
>> + if (group) {
>> + iommu_group_get_by_id(iommu_group_id(group));
>> return group;
>
>This might as well just be inline, i.e.:
>
> return iommu_group_get_by_id(iommu_group_id(group));
>
>It's a shame we have to go all round the houses when we have the group
>right there, but this is probably the most expedient fix. I guess we can
>extend the API with some sort of iommu_group_get(group) overload in
>future if we really want to.
>
ok, i can send this fix separately then. Otherwise, Will was suggesting on the
other thread that there should probably be a separate API to increment
the group refcount or get the group from the existing aliasing device.
As per me adding the api, looks like another option or post the above ?
Regards,
Sricharan
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-09 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f36244f-62d4-08e3-d64a-2b04ad4dc2e0@arm.com>
Hi Robin,
>On 04/11/16 15:16, Sricharan wrote:
>> Hi Robin,
>>
>>>>> Yikes, on second look, that definitely shouldn't be happening.
>>>>> Everything below is probably the resulting fallout.
>>>>
>>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>>>
>>>> I think the above print which says "failed to setup iommu_ops"
>>>> because the call ops->add_device failed in of_pci_iommu_configure
>>>> is the reason for the failure, in my case i simply do not get this even with
>>>> your scripts. ops->add_device succeeds in the rebind as well. So still
>>>> checking what could be happening in your case.
>>>
>>> I was looking at your code base from [1].The ops->add_device
>>> callback from of_pci_iommu_configure on the rebind is the
>>> one which is causing the failure. But not able to spot out
>>>from code which point is causing the failure. It would be very helpful
>>> if i can know which is the return value from the add_device callback
>>> or point inside add_device callback which fails in your setup.
>>>
>>>
>>> [1] git://linux-arm.org/linux-rm iommu/misc
>>
>> With little more try, i saw an issue where i had an failure
>> similar to what you reported. The issue happens when multiple
>> devices fall in to same group due to matching sids. I ended up
>> doing a fix like below and it would be nice to verify if it is the same
>> that we are seeing in your setup and if the fix makes a difference ?
>>
>> From: Sricharan R <sricharan@codeaurora.org>
>> Date: Fri, 4 Nov 2016 20:28:49 +0530
>> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>>
>> iommu_group_get_for_dev which gets called in the add_device
>> callback, increases the reference count of the iommu_group,
>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>> inturn calls device_group callback and in the case of arm-smmu
>> we call generic_device_group/pci_device_group which takes
>> care of increasing the group's reference. But when we return
>> an already existing group(when multiple devices have same group)
>> the reference is not incremented, resulting in issues when the
>> remove_device callback for the devices is invoked.
>> Fixing the same here.
>
>Bah, yes, this does look like my fault - after flip-flopping between
>about 3 different ways to keep refcounts for the S2CR entries, none of
>which would quite work, I ripped it all out but apparently still got
>things wrong, oh well. Thanks for figuring it out.
>
>On the probe-deferral angle, whilst it's useful to have uncovered this
>bug, I don't think we should actually be calling remove_device() from
>DMA teardown. I think it's preferable from a user perspective if group
>numbering remains stable, rather than changing depending on the order in
>which they unbind/rebind VFIO drivers. I'm really keen to try and get
>this in shape for 4.10, so I've taken the liberty of hacking up my own
>branch (iommu/defer) based on v3 - would you mind taking a look at the
>two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>to your later patches - that was an experiment which didn't really work out)
Ok, will take a look at this now and respond more on this.
>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 71ce4b6..a1d0b3c 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
>> group = smmu->s2crs[idx].group;
>> }
>>
>> - if (group)
>> + if (group) {
>> + iommu_group_get_by_id(iommu_group_id(group));
>> return group;
>
>This might as well just be inline, i.e.:
>
> return iommu_group_get_by_id(iommu_group_id(group));
>
>It's a shame we have to go all round the houses when we have the group
>right there, but this is probably the most expedient fix. I guess we can
>extend the API with some sort of iommu_group_get(group) overload in
>future if we really want to.
>
ok, i can send this fix separately then. Otherwise, Will was suggesting on the
other thread that there should probably be a separate API to increment
the group refcount or get the group from the existing aliasing device.
As per me adding the api, looks like another option or post the above ?
Regards,
Sricharan
^ permalink raw reply
* bump librados' soversion
From: kefu chai @ 2016-11-09 6:16 UTC (permalink / raw)
To: ceph-devel@vger.kernel.org, Sage Weil, dillaman
hi cephers,
i am proposing bumping the soversion of librados2 to librados3. as in
053bfa6[0], we changed the function signature of
ceph::buffer::list::advance(), which is incompatible with the prior
version of librados. that's partially why we have
http://tracker.ceph.com/issues/17809, in which, the old librbd client
fails to start, due to unresolved symbols.
and if user has some (homebrew) packages depending on librados2. those
packages will be broken as well. the same applies to executables
linked against librados2 shared library. so we need to bump the
soversion. but to minimize the impact, i think we will not introduce
incompatible changes between major releases, in other words, the
soversion won't change from jewel to kraken, for example. if i
understand sage's comment correctly.
yes, i knew this issue was raised before from time to time. but maybe
this is a good chance to do the soversion change in kraken.
a PR is posted to address this problem. see
https://github.com/ceph/ceph/pull/11843.
--
[0] https://github.com/ceph/ceph/pull/9395/commits/053bfa650ba1d656dfb20e389ef25afc4c383bb3
[1] https://github.com/ceph/ceph/pull/9395#issuecomment-224278945
--
Regards
Kefu Chai
^ permalink raw reply
* Re: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
From: Greg KH @ 2016-11-09 6:11 UTC (permalink / raw)
To: Stefan Agner; +Cc: stable, Wolfram Sang, stable
In-Reply-To: <847750bba7bed752906f75f5df3f8344@agner.ch>
On Tue, Nov 08, 2016 at 04:34:50PM -0800, Stefan Agner wrote:
> On 2016-11-08 16:32, Stefan Agner wrote:
> > commit 533169d164c6b4c8571d0d48779f6ff6be593d72 upstream.
> >
> > Some SoC might load the GPIO driver after the I2C driver and
> > using the I2C bus recovery mechanism via GPIOs. In this case
> > it is crucial to defer probing if the GPIO request functions
> > do so, otherwise the I2C driver gets loaded without recovery
> > mechanisms enabled.
> >
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > Acked-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
> > Acked-by: Li Yang <leoyang.li@nxp.com>
> > Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> > Cc: stable@kernel.org
>
> I forgot to mention, this should be applied to 4.4 only.
Did you build the code there?
> Later versions made the return value void, and it would require a larger
> rework. I am mainly concerned about LTS...
I don't see this working for either 4.4 or 4.8-stable right now, do you?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
From: Greg KH @ 2016-11-09 6:10 UTC (permalink / raw)
To: Stefan Agner; +Cc: stable, Wolfram Sang, stable
In-Reply-To: <20161109003239.16940-1-stefan@agner.ch>
On Tue, Nov 08, 2016 at 04:32:39PM -0800, Stefan Agner wrote:
> commit 533169d164c6b4c8571d0d48779f6ff6be593d72 upstream.
>
> Some SoC might load the GPIO driver after the I2C driver and
> using the I2C bus recovery mechanism via GPIOs. In this case
> it is crucial to defer probing if the GPIO request functions
> do so, otherwise the I2C driver gets loaded without recovery
> mechanisms enabled.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
> Acked-by: Li Yang <leoyang.li@nxp.com>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> Cc: stable@kernel.org
> ---
> drivers/i2c/busses/i2c-imx.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index d4d8536..32fae2c 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1002,10 +1002,13 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
> rinfo->scl_gpio = of_get_named_gpio_flags(pdev->dev.of_node,
> "scl-gpios", 0, NULL);
>
> - if (!gpio_is_valid(rinfo->sda_gpio) ||
> - !gpio_is_valid(rinfo->scl_gpio) ||
> - IS_ERR(i2c_imx->pinctrl_pins_default) ||
> - IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> + if (rinfo->sda_gpio == -EPROBE_DEFER ||
> + rinfo->scl_gpio == -EPROBE_DEFER) {
> + return -EPROBE_DEFER;
Ok, but...
> + } else if (!gpio_is_valid(rinfo->sda_gpio) ||
> + !gpio_is_valid(rinfo->scl_gpio) ||
> + IS_ERR(i2c_imx->pinctrl_pins_default) ||
> + IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> dev_dbg(&pdev->dev, "recovery information incomplete\n");
> return;
Hm.
I don't think you built this patch :(
Same goes for 4.8-stable...
greg k-h
^ permalink raw reply
* Re: [PATCH 1/3] kbuild: add -fno-PIE
From: Ingo Molnar @ 2016-11-09 6:10 UTC (permalink / raw)
To: Michal Marek
Cc: Sebastian Andrzej Siewior, linux-kernel, linux-kbuild, x86,
Al Viro, Ben Hutchings, Sven Joachim, Austin S. Hemmelgarn,
Borislav Petkov
In-Reply-To: <20161108221437.GA9197@sepie.suse.cz>
* Michal Marek <mmarek@suse.com> wrote:
> On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote:
> > Debian started to build the gcc with -fPIE by default so the kernel
> > build ends before it starts properly with:
> > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
> >
> > Also add to KBUILD_AFLAGS due to:
> >
> > |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
> > |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic
> >
> > Tagging it stable so it is possible to compile recent stable kernels as
> > well.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> > Makefile | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index a2650f9c6a25..d61145ebf498 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -622,6 +622,8 @@ include arch/$(SRCARCH)/Makefile
> > KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
> > KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
> > KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
> > +KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
> > +KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
>
> Bad compiler. No pie for you.
>
> I applied this one to kbuild.git. How about 2/3 and 3/3. Will these be
> merged via tip.git or shall I apply them as well?
I'd suggest applying them to the kbuild tree, as they are related.
Thanks,
Ingo
^ permalink raw reply
* Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]
From: Linus Torvalds @ 2016-11-09 6:08 UTC (permalink / raw)
To: Feng Tang
Cc: Ville Syrjälä, Thomas Gleixner, Feng Tang,
Rafael J. Wysocki, Wysocki, Rafael J, Steven Rostedt,
Sebastian Andrzej Siewior, linux-arch@vger.kernel.org,
Rik van Riel, Srivatsa S. Bhat, Peter Zijlstra, Arjan van de Ven,
Rusty Russell, Oleg Nesterov, Tejun Heo, Andrew Morton,
Paul McKenney, Paul Turner, Linux Kernel Mailing List, Zhang, Rui,
Brown, Len, Linux PM, Linux ACPI
In-Reply-To: <20161109035418.GA18246@shbuild888>
On Tue, Nov 8, 2016 at 7:54 PM, Feng Tang <feng.tang@intel.com> wrote:
> On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
>>
>> I left the thing running for the weekend and it failed 26 out of 16057
>> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
>> when it fails, but eventually it does come back.
>
> Just came back from a travel. Yes, the 5 minutes delay may be due to the
> expiration of the HPET timer, counting from 0 to 0xffffffff for a 13M
> frequencey HPET takes about 300 seconds. After resume, it seems nobody
> arms it so my old patch forces to arm one event.
Ville, what happens if you disable HPET? Can you force the TSC with
"clocksource=tsc" or "tsc=reliable". Does resume work reliably then?
Or is this one of the CPU's where tsc just doesn't work?
Linus
^ permalink raw reply
* Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]
From: Linus Torvalds @ 2016-11-09 6:08 UTC (permalink / raw)
To: Feng Tang
Cc: Ville Syrjälä, Thomas Gleixner, Feng Tang,
Rafael J. Wysocki, Wysocki, Rafael J, Steven Rostedt,
Sebastian Andrzej Siewior, linux-arch@vger.kernel.org,
Rik van Riel, Srivatsa S. Bhat, Peter Zijlstra, Arjan van de Ven,
Rusty Russell, Oleg Nesterov, Tejun Heo, Andrew Morton,
Paul McKenney, Paul Turner
In-Reply-To: <20161109035418.GA18246@shbuild888>
On Tue, Nov 8, 2016 at 7:54 PM, Feng Tang <feng.tang@intel.com> wrote:
> On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
>>
>> I left the thing running for the weekend and it failed 26 out of 16057
>> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
>> when it fails, but eventually it does come back.
>
> Just came back from a travel. Yes, the 5 minutes delay may be due to the
> expiration of the HPET timer, counting from 0 to 0xffffffff for a 13M
> frequencey HPET takes about 300 seconds. After resume, it seems nobody
> arms it so my old patch forces to arm one event.
Ville, what happens if you disable HPET? Can you force the TSC with
"clocksource=tsc" or "tsc=reliable". Does resume work reliably then?
Or is this one of the CPU's where tsc just doesn't work?
Linus
^ permalink raw reply
* RE: [PATCH v1] ufs: introduce setup_hibern8 callback
From: Kiwoong Kim @ 2016-11-09 6:08 UTC (permalink / raw)
To: 'Subhash Jadavani'
Cc: 'James E.J. Bottomley', linux-scsi,
'Martin K. Petersen', vinholikatti, '???',
linux-scsi-owner, cpgs
In-Reply-To: <2b929a73cd7e0f63821383deec9bcac6@codeaurora.org>
> > Some UFS host controller may need to configure some things around
> > hibern8 enter/exit
> >
> > Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
> > ---
> > drivers/scsi/ufs/ufshcd.c | 10 ++++++++-- drivers/scsi/ufs/ufshcd.h
> > | 10 ++++++++++
> > 2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index fdb0502..d4a5a9c 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -2697,6 +2697,8 @@ static int __ufshcd_uic_hibern8_enter(struct
> > ufs_hba *hba)
> > int ret;
> > struct uic_command uic_cmd = {0};
> >
> > + ufshcd_vops_setup_hibern8(hba, true, PRE_CHANGE);
> > +
> > uic_cmd.command = UIC_CMD_DME_HIBER_ENTER;
> > ret = ufshcd_uic_pwr_ctrl(hba, &uic_cmd);
> >
> > @@ -2710,7 +2712,8 @@ static int __ufshcd_uic_hibern8_enter(struct
> > ufs_hba *hba)
> > */
> > if (ufshcd_link_recovery(hba))
> > ret = -ENOLINK;
> > - }
> > + } else
> > + ufshcd_vops_setup_hibern8(hba, true, POST_CHANGE);
> >
> > return ret;
> > }
> > @@ -2733,13 +2736,16 @@ static int ufshcd_uic_hibern8_exit(struct
> > ufs_hba *hba)
> > struct uic_command uic_cmd = {0};
> > int ret;
> >
> > + ufshcd_vops_setup_hibern8(hba, false, PRE_CHANGE);
> > +
> > uic_cmd.command = UIC_CMD_DME_HIBER_EXIT;
> > ret = ufshcd_uic_pwr_ctrl(hba, &uic_cmd);
> > if (ret) {
> > dev_err(hba->dev, "%s: hibern8 exit failed. ret = %d\n",
> > __func__, ret);
> > ret = ufshcd_link_recovery(hba);
> > - }
> > + } else
> > + ufshcd_vops_setup_hibern8(hba, false, POST_CHANGE);
> >
> > return ret;
> > }
> > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> > index b084d89..13504b4 100644
> > --- a/drivers/scsi/ufs/ufshcd.h
> > +++ b/drivers/scsi/ufs/ufshcd.h
> > @@ -265,6 +265,8 @@ struct ufs_pwr_mode_info {
> > * to set some things
> > * @setup_task_mgmt: called before any task management request is
> > issued
> > * to set some things
> > + * @setup_hibern8: called around hibern8 enter/exit
> > + * to configure some things
> > * @suspend: called during host controller PM callback
> > * @resume: called during host controller PM callback
> > * @dbg_register_dump: used to dump controller debug information @@
> > -290,6 +292,7 @@ struct ufs_hba_variant_ops {
> > struct ufs_pa_layer_attr *);
> > void (*setup_xfer_req)(struct ufs_hba *, int, bool);
> > void (*setup_task_mgmt)(struct ufs_hba *, int, u8);
> > + void (*setup_hibern8)(struct ufs_hba *, bool, bool);
>
> Can we change the name to "hibern8_notify" ? You may check other
> ufs_hba_variant_ops for reference.
Okay, I'll apply what you said.
>
> > int (*suspend)(struct ufs_hba *, enum ufs_pm_op);
> > int (*resume)(struct ufs_hba *, enum ufs_pm_op);
> > void (*dbg_register_dump)(struct ufs_hba *hba);
> > @@ -821,6 +824,13 @@ static inline void
> > ufshcd_vops_setup_task_mgmt(struct ufs_hba *hba,
> > return hba->vops->setup_task_mgmt(hba, tag, tm_function); }
> >
> > +static inline void ufshcd_vops_setup_hibern8(struct ufs_hba *hba,
> > + bool enter, bool notify)
>
> Using bool to specify whether it is hibern8 enter or hibern8 exit doesn't
> seem to be readable. May be you can pass the UIC_CMD_DME_HIBER_ENTER or
> UIC_CMD_DME_HIBER_EXIT (in other words use "enum uic_cmd_dme" type).
>
> also "notify" type should be changed from "bool" to "enum
> ufs_notify_change_status".
Okay, I'll apply what you said and use "enum uic_cmd_dme"
as 2nd argument date type.
>
> > +{
> > + if (hba->vops && hba->vops->setup_hibern8)
> > + return hba->vops->setup_hibern8(hba, enter, notify); }
> > +
> > static inline int ufshcd_vops_suspend(struct ufs_hba *hba, enum
> > ufs_pm_op op) {
> > if (hba->vops && hba->vops->suspend)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ASoC: lpass-platform: initialize dma channel number
From: Kenneth Westfield @ 2016-11-09 6:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Brown, Patrick Lai, Banajit Goswami, Liam Girdwood,
Srinivas Kandagatla, Kenneth Westfield, alsa-devel, linux-kernel
In-Reply-To: <20161108133916.1742379-1-arnd@arndb.de>
On Tue, Nov 08, 2016 at 02:38:52PM +0100, Arnd Bergmann wrote:
> A bugfix accidentally removed the implicit initialization of the
> dma channel number, causing undefined behavior when
> v->alloc_dma_channel is NULL:
>
> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
> sound/soc/qcom/lpass-platform.c:83:29: error: ‘dma_ch’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This adds back an explicit initialization to zero, restoring the
> previous behavior for that case.
>
> Fixes: 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/qcom/lpass-platform.c | 3 +++
> 1 file changed, 3 insertions(+)
Good catch.
Acked-by: Kenneth Westfield <kwestfie@codeaurora.org>
--
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [Qemu-devel] [RFC 15/17] ppc: Check that CPU model stays consistent across migration
From: Alexey Kardashevskiy @ 2016-11-09 6:06 UTC (permalink / raw)
To: David Gibson; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <20161109042407.GE427@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 4929 bytes --]
On 09/11/16 15:24, David Gibson wrote:
> On Tue, Nov 08, 2016 at 05:03:49PM +1100, Alexey Kardashevskiy wrote:
>> On 08/11/16 16:29, David Gibson wrote:
>>> On Fri, Nov 04, 2016 at 06:54:48PM +1100, Alexey Kardashevskiy wrote:
>>>> On 30/10/16 22:12, David Gibson wrote:
>>>>> When a vmstate for the ppc cpu was first introduced (a90db15 "target-ppc:
>>>>> Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was used
>>>>> to ensure that identical CPU models were used at source and destination
>>>>> as based on the PVR (Processor Version Register).
>>>>>
>>>>> However this was a problem for HV KVM, where due to hardware limitations
>>>>> we always need to use the real PVR of the host CPU. So, to allow
>>>>> migration between hosts with "similar enough" CPUs, the PVR check was
>>>>> removed in 569be9f0 "target-ppc: Remove PVR check from migration". This
>>>>> left the onus on user / management to only attempt migration between
>>>>> compatible CPUs.
>>>>>
>>>>> Now that we've reworked the handling of compatiblity modes, we have the
>>>>> information to actually determine if we're making a compatible migration.
>>>>> So this patch partially restores the PVR check. If the source was running
>>>>> in a compatibility mode, we just make sure that the destination cpu can
>>>>> also run in that compatibility mode. However, if the source was running
>>>>> in "raw" mode, we verify that the destination has the same PVR value.
>>>>>
>>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>>> ---
>>>>> target-ppc/machine.c | 15 +++++++++++----
>>>>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
>>>>> index 5d87ff6..62b9e94 100644
>>>>> --- a/target-ppc/machine.c
>>>>> +++ b/target-ppc/machine.c
>>>>> @@ -173,10 +173,12 @@ static int cpu_post_load(void *opaque, int version_id)
>>>>> target_ulong msr;
>>>>>
>>>>> /*
>>>>> - * We always ignore the source PVR. The user or management
>>>>> - * software has to take care of running QEMU in a compatible mode.
>>>>> + * If we're operating in compat mode, we should be ok as long as
>>>>> + * the destination supports the same compatiblity mode.
>>>>> + *
>>>>> + * Otherwise, however, we require that the destination has exactly
>>>>> + * the same CPU model as the source.
>>>>> */
>>>>> - env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
>>>>>
>>>>> #if defined(TARGET_PPC64)
>>>>> if (cpu->compat_pvr) {
>>>>> @@ -188,8 +190,13 @@ static int cpu_post_load(void *opaque, int version_id)
>>>>> error_free(local_err);
>>>>> return -1;
>>>>> }
>>>>> - }
>>>>> + } else
>>>>> #endif
>>>>> + {
>>>>> + if (env->spr[SPR_PVR] != env->spr_cb[SPR_PVR].default_value) {
>>>>> + return -1;
>>>>> + }
>>>>> + }
>>>>
>>>> This should break migration from host with PVR=004d0200 to host with
>>>> PVR=004d0201, what is the benefit of such limitation?
>>>
>>> There probably isn't one. But the point is it also blocks migration
>>> from a host with PVR=004B0201 (POWER8) to one with PVR=00201400
>>> (403GCX) and *that* has a clear benefit. I don't see a way to block
>>> the second without the first, except by creating a huge compatibility
>>> matrix table, which would require inordinate amounts of time to
>>> research carefully.
>>
>>
>> This is pcc->pvr_match() for this purpose.
>
> Hmm.. thinking about this. Obviously requiring an exactly matching
> PVR is the architecturally "safest" approach. For TCG and PR KVM, it
> really should be sufficient - if you can select "close" PVRs at each
> end, you should be able to select exactly matching ones just as well.
>
> For HV KVM, we should generally be using compatibility modes to allow
> migration between a relatively wide range of CPUs. My intention was
> basically to require moving to that model, rather than "approximate
> matching" real PVRs.
So the management stack (libvirt) will need to know that if it is HV KVM,
then -cpu host,compat=xxxx; if it is PR KVM, then -cpu XXXX and no compat.
That was really annoying when we had exact PVR matching.
> I'm still convinced using compat modes is the right way to go medium
> to long term. However, allowing the approximate matches could make
> for a more forgiving transition, if people have existing hosts in
> "raw" mode.
Within the family, CPUs behave exactly (not slightly but exactly) the same
even though 3 of 4 bytes of the PVR value are different so enforcing PVR to
match or enforcing compatibility (which as a feature was not a great idea
from the day one) does not sound compelling.
Does x86 have anything like this compatibility thingy?
> Ok, I'll add pvr_match checking to this.
>
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 839 bytes --]
^ permalink raw reply
* [RFC 3/3] char: add icc_char device
From: fixed-term.Oleksij.Rempel @ 2016-11-09 6:04 UTC (permalink / raw)
To: linux-kernel, linux-soc, dirk.behme, mkl; +Cc: Oleksij Rempel, Oleksij Rempel
In-Reply-To: <1478671461-25135-1-git-send-email-fixed-term.Oleksij.Rempel@de.bosch.com>
From: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
This is simple interface to talk over SSI32 bus.
For testing fallwoing commands can be used:
while true; do cat /dev/iccch015 | hexdump; done &
while true; do echo 1 > /dev/iccch015; done
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
---
drivers/char/Kconfig | 9 ++
drivers/char/Makefile | 1 +
drivers/char/icc_char.c | 280 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 290 insertions(+)
create mode 100644 drivers/char/icc_char.c
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a4af822..e610173 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -611,5 +611,14 @@ config TILE_SROM
source "drivers/char/xillybus/Kconfig"
+config ICC_CHAR
+ tristate "ICC char interface"
+ depends on ICC
+ default y
+ help
+ If you say yes here you get char device communication over
+ ICC bus.
+
+
endmenu
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index d06cde26..0439daa 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -62,3 +62,4 @@ js-rtc-y = rtc.o
obj-$(CONFIG_TILE_SROM) += tile-srom.o
obj-$(CONFIG_XILLYBUS) += xillybus/
+obj-$(CONFIG_ICC_CHAR) += icc_char.o
diff --git a/drivers/char/icc_char.c b/drivers/char/icc_char.c
new file mode 100644
index 0000000..a4005c7
--- /dev/null
+++ b/drivers/char/icc_char.c
@@ -0,0 +1,280 @@
+/*
+ * Char device for ICC bus.
+ *
+ * Copyright (C) Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/cdev.h>
+#include <linux/fs.h>
+#include <linux/icc/icc.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/proc_fs.h>
+#include <linux/wait.h>
+#include <linux/sched.h>
+
+#include <asm/uaccess.h>
+
+static unsigned int icc_ch_major;
+
+struct icc_ch_priv {
+ struct device *dev;
+ struct icc_device *iccd;
+ struct cdev cdev;
+
+
+ struct icc_trf trf;
+ void *rx_buf;
+ size_t rx_buf_size;
+ struct mutex rx_buf_lock;
+ wait_queue_head_t rx_wq;
+};
+
+static int icc_ch_int_trf(struct icc_ch_priv *priv)
+{
+ struct icc_device *iccd = priv->iccd;
+ struct icc_master *iccm = iccd->iccm;
+ struct icc_trf *trf = &priv->trf;
+ int ret;
+
+ ret = icc_trf_alloc(iccm, trf, iccd->lun_number,
+ iccm->max_data_size);
+ if (ret)
+ return ret;
+
+ priv->rx_buf = devm_kzalloc(priv->dev, iccm->max_data_size,
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static ssize_t icc_ch_fop_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *pos)
+{
+ struct icc_ch_priv *priv = file->private_data;
+ struct icc_device *iccd = priv->iccd;
+ struct icc_master *iccm = iccd->iccm;
+ int ret;
+
+ if (count > iccm->max_data_size)
+ return -EINVAL;
+
+ count = min(count, (size_t)iccm->max_data_size);
+ if (copy_from_user(priv->trf.data, buf, count))
+ return -EFAULT;
+
+ priv->trf.data_size = count;
+
+ ret = icc_trf_xmit(iccm, &priv->trf);
+ if (ret)
+ return ret;
+
+ return count;
+}
+
+static int icc_ch_wait(struct icc_ch_priv *priv) {
+ return wait_event_interruptible(priv->rx_wq, priv->rx_buf_size);
+}
+
+static void icc_ch_wake(struct icc_ch_priv *priv) {
+ wake_up_interruptible(&priv->rx_wq);
+}
+
+static ssize_t icc_ch_fop_read(struct file *file, char *buf,
+ size_t count, loff_t *ppos)
+{
+ struct icc_ch_priv *priv = file->private_data;
+ size_t ret = 0;
+
+ if (*ppos != 0)
+ return 0;
+
+ ret = icc_ch_wait(priv);
+ if (ret)
+ return ret;
+
+ mutex_lock(&priv->rx_buf_lock);
+
+ if (!priv->rx_buf_size) {
+ ret = 0;
+ goto done;
+ }
+
+ if (count < priv->rx_buf_size) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ if (copy_to_user(buf, priv->rx_buf, priv->rx_buf_size)) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ ret = *ppos = priv->rx_buf_size;
+ priv->rx_buf_size = 0;
+
+ mutex_unlock(&priv->rx_buf_lock);
+
+done:
+ return ret;
+}
+
+static int icc_ch_fop_open(struct inode *ino, struct file *file)
+{
+ file->private_data =
+ container_of(ino->i_cdev, struct icc_ch_priv, cdev);
+
+ return 0;
+}
+
+static const struct file_operations icc_ch_fops = {
+ .owner = THIS_MODULE,
+ .open = icc_ch_fop_open,
+ .read = icc_ch_fop_read,
+ .write = icc_ch_fop_write,
+};
+
+static int icc_ch_rx_cb(struct icc_device *iccd, void *rx_buf, size_t size)
+{
+ struct icc_ch_priv *priv = icc_get_drvdata(iccd);
+
+ /*
+ * if we can't transfer it no, drop it
+ * allow other do the job
+ */
+ if (!mutex_trylock(&priv->rx_buf_lock))
+ return -EBUSY;
+
+ /*
+ * TODO: we should decide what kind of logic do we use.
+ * For example for GPS it would make no match sense to
+ * keep old and not valid data.
+ * For now, let's be save and keep it.
+ */
+ if (priv->rx_buf_size) {
+ mutex_unlock(&priv->rx_buf_lock);
+ return -EBUSY;
+ }
+
+ memcpy(priv->rx_buf, rx_buf, size);
+ priv->rx_buf_size = size;
+
+ mutex_unlock(&priv->rx_buf_lock);
+ icc_ch_wake(priv);
+
+ return 0;
+}
+
+static int icc_ch_probe(struct icc_device *iccd)
+{
+ struct icc_master *iccm = iccd->iccm;
+ struct device *dev = &iccd->dev;
+ struct device *dev1;
+ struct icc_ch_priv *priv;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(struct icc_ch_priv),
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ priv->iccd = iccd;
+ mutex_init(&priv->rx_buf_lock);
+ init_waitqueue_head(&priv->rx_wq);
+
+ icc_set_drvdata(iccd, priv);
+ icc_set_rxcb(iccd, icc_ch_rx_cb);
+
+ ret = icc_ch_int_trf(priv);
+ if (ret)
+ return ret;
+
+ cdev_init(&priv->cdev, &icc_ch_fops);
+ priv->cdev.owner = THIS_MODULE;
+ ret = cdev_add(&priv->cdev, MKDEV(icc_ch_major, iccd->lun_number), 1);
+ if (ret) {
+ dev_err(dev, "filed to add cdev\n");
+ return ret;
+ }
+
+ dev1 = device_create(iccm->icc_class, dev,
+ MKDEV(icc_ch_major, iccd->lun_number),
+ priv, "iccch%03d", iccd->lun_number);
+
+ if (IS_ERR(dev1)) {
+ dev_info(dev, "ICC chardev filed: %i\n", PTR_ERR(dev1));
+ return PTR_ERR(dev1);
+ }
+
+ dev_info(dev, "ICC chardev enabled\n");
+ return 0;
+}
+
+static int icc_ch_remove(struct icc_device *iccd)
+{
+ struct icc_master *iccm = iccd->iccm;
+
+ device_destroy(iccm->icc_class,
+ MKDEV(icc_ch_major, iccd->lun_number));
+ return 0;
+}
+
+static const struct of_device_id icc_ch_of_match[] = {
+ { .compatible = "rbcm,ssi32-char-v1" },
+ { .compatible = "rbcm,icc-char-v1" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, icc_ch_of_match);
+
+static struct icc_driver icc_ch_driver = {
+ .driver = {
+ .name = "icc-ch",
+ .owner = THIS_MODULE,
+ .of_match_table = icc_ch_of_match,
+ },
+ .probe = icc_ch_probe,
+ .remove = icc_ch_remove,
+};
+
+static int __init icc_ch_init(void)
+{
+ static dev_t dev;
+ int ret;
+
+ ret = alloc_chrdev_region(&dev, 0, ICC_MAX_LUNS, "iccch");
+ if (ret)
+ pr_err("Unable to register ICC chdev region\n");
+
+ icc_ch_major = MAJOR(dev);
+
+ ret = icc_register_driver(&icc_ch_driver);
+ if (ret)
+ pr_err("Unable to register ICC chdev\n");
+
+ return ret;
+}
+
+module_init(icc_ch_init);
+
+static void __exit
+icc_ch_exit(void)
+{
+ icc_unregister_driver(&icc_ch_driver);
+ unregister_chrdev_region(MKDEV(icc_ch_major, 0), ICC_MAX_LUNS);
+}
+
+module_exit(icc_ch_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>");
+MODULE_DESCRIPTION("ICC chardev");
--
1.9.1
^ permalink raw reply related
* [RFC 1/3] icc: add add SSI32 transport driver
From: fixed-term.Oleksij.Rempel @ 2016-11-09 6:04 UTC (permalink / raw)
To: linux-kernel, linux-soc, dirk.behme, mkl; +Cc: Oleksij Rempel, Oleksij Rempel
In-Reply-To: <1478671461-25135-1-git-send-email-fixed-term.Oleksij.Rempel@de.bosch.com>
From: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
Add driver for Inter-Chip communication based on SSI32 protocol.
SSI32 is Synchronous Serial Interface optimised for 32bit alignment.
It is an Transport protocol based on SPI used for industrie devices
designed with fallowing points in mind:
- implementation with widely available and cheap technology - SPI.
- error detection and response within 1 milli seccond.
- fixed size messages.
- Acknowledgment between applications.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
---
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/icc/Kconfig | 13 ++
drivers/icc/Makefile | 5 +
drivers/icc/icc_bus.c | 204 ++++++++++++++++++++++++++
drivers/icc/ssi32/Kconfig | 12 ++
drivers/icc/ssi32/Makefile | 6 +
drivers/icc/ssi32/ssi32_prot.c | 256 ++++++++++++++++++++++++++++++++
drivers/icc/ssi32/ssi32_prot.h | 94 ++++++++++++
drivers/icc/ssi32/ssi32_spi_hif.c | 300 ++++++++++++++++++++++++++++++++++++++
drivers/icc/ssi32/ssi32_spi_hif.h | 40 +++++
include/linux/icc/icc.h | 88 +++++++++++
include/linux/icc/ssi32.h | 32 ++++
13 files changed, 1053 insertions(+)
create mode 100644 drivers/icc/Kconfig
create mode 100644 drivers/icc/Makefile
create mode 100644 drivers/icc/icc_bus.c
create mode 100644 drivers/icc/ssi32/Kconfig
create mode 100644 drivers/icc/ssi32/Makefile
create mode 100644 drivers/icc/ssi32/ssi32_prot.c
create mode 100644 drivers/icc/ssi32/ssi32_prot.h
create mode 100644 drivers/icc/ssi32/ssi32_spi_hif.c
create mode 100644 drivers/icc/ssi32/ssi32_spi_hif.h
create mode 100644 include/linux/icc/icc.h
create mode 100644 include/linux/icc/ssi32.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..acc9b08 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -56,6 +56,8 @@ source "drivers/spmi/Kconfig"
source "drivers/hsi/Kconfig"
+source "drivers/icc/Kconfig"
+
source "drivers/pps/Kconfig"
source "drivers/ptp/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 527a6da..6656a1e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_MTD) += mtd/
obj-$(CONFIG_SPI) += spi/
obj-$(CONFIG_SPMI) += spmi/
obj-y += hsi/
+obj-y += icc/
obj-y += net/
obj-$(CONFIG_ATM) += atm/
obj-$(CONFIG_FUSION) += message/
diff --git a/drivers/icc/Kconfig b/drivers/icc/Kconfig
new file mode 100644
index 0000000..33b6422
--- /dev/null
+++ b/drivers/icc/Kconfig
@@ -0,0 +1,13 @@
+#
+# ICC driver configuration
+#
+menuconfig ICC
+ tristate "ICC support"
+ ---help---
+ The "Inter-Chip Communication" support
+
+if ICC
+
+source "drivers/icc/ssi32/Kconfig"
+
+endif # ICC
diff --git a/drivers/icc/Makefile b/drivers/icc/Makefile
new file mode 100644
index 0000000..c3662c0
--- /dev/null
+++ b/drivers/icc/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for ICC
+#
+obj-$(CONFIG_ICC) += icc_bus.o
+obj-y += ssi32/
diff --git a/drivers/icc/icc_bus.c b/drivers/icc/icc_bus.c
new file mode 100644
index 0000000..dceb47c
--- /dev/null
+++ b/drivers/icc/icc_bus.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2016 Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/compiler.h>
+#include <linux/list.h>
+#include <linux/kobject.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/notifier.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/module.h>
+#include <linux/icc/icc.h>
+
+static struct class *icc_class;
+
+static ssize_t modalias_show(struct device *dev,
+ struct device_attribute *a __maybe_unused,
+ char *buf)
+{
+ return sprintf(buf, "icc:%s\n", dev_name(dev));
+}
+static DEVICE_ATTR_RO(modalias);
+
+static struct attribute *icc_bus_dev_attrs[] = {
+ &dev_attr_modalias.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(icc_bus_dev);
+
+static int icc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ add_uevent_var(env, "MODALIAS=icc:%s", dev_name(dev));
+
+ return 0;
+}
+
+static int icc_bus_match(struct device *dev, struct device_driver *drv)
+{
+ if (of_driver_match_device(dev, drv))
+ return true;
+
+ if (strcmp(dev_name(dev), drv->name) == 0)
+ return true;
+
+ return false;
+}
+
+static struct bus_type icc_bus_type = {
+ .name = "icc",
+ .dev_groups = icc_bus_dev_groups,
+ .match = icc_bus_match,
+ .uevent = icc_bus_uevent,
+};
+
+static int icc_drv_probe(struct device *dev)
+{
+ const struct icc_driver *icc_drv = to_icc_driver(dev->driver);
+ struct icc_device *iccd = to_icc_device(dev);
+
+ return icc_drv->probe(iccd);
+}
+
+static int icc_drv_remove(struct device *dev)
+{
+ const struct icc_driver *icc_drv = to_icc_driver(dev->driver);
+ struct icc_device *iccd = to_icc_device(dev);
+
+ return icc_drv->remove(iccd);
+}
+
+static void icc_drv_shutdown(struct device *dev)
+{
+ const struct icc_driver *icc_drv = to_icc_driver(dev->driver);
+ struct icc_device *iccd = to_icc_device(dev);
+
+ icc_drv->shutdown(iccd);
+}
+
+int icc_register_driver(struct icc_driver *icc_drv)
+{
+ icc_drv->driver.bus = &icc_bus_type;
+
+ if (icc_drv->probe)
+ icc_drv->driver.probe = icc_drv_probe;
+ if (icc_drv->remove)
+ icc_drv->driver.remove = icc_drv_remove;
+ if (icc_drv->shutdown)
+ icc_drv->driver.shutdown = icc_drv_shutdown;
+
+ return driver_register(&icc_drv->driver);
+}
+EXPORT_SYMBOL_GPL(icc_register_driver);
+
+void icc_unregister_driver(struct icc_driver *icc_drv)
+{
+ return driver_unregister(&icc_drv->driver);
+}
+EXPORT_SYMBOL_GPL(icc_unregister_driver);
+
+static void icc_lun_release(struct device *dev)
+{
+}
+
+static int icc_add_lun_from_dt(struct icc_master *iccm,
+ struct device_node *np)
+{
+ struct icc_device *iccd;
+ u32 reg;
+ int ret;
+
+ ret = of_property_read_u32(np, "reg", ®);
+ if (ret) {
+ dev_warn(iccm->dev, "can't parse \"reg\" for %s\n",
+ np->full_name);
+ return ret;
+ }
+
+ if (reg > ICC_MAX_LUNS) {
+ dev_warn(iccm->dev, "reg is more then %i\n",
+ ICC_MAX_LUNS);
+ return -EINVAL;
+ }
+
+ iccd = &iccm->lun[reg];
+
+ if (iccd->configured) {
+ dev_warn(iccm->dev, "lun %i is already configured\n",
+ reg);
+ return -EINVAL;
+ }
+
+ /* TODO: set some usaable name */
+ dev_set_name(&iccd->dev, "%s:lun.%i:%s", dev_name(iccm->dev),
+ reg, np->name);
+
+ iccd->dev.bus = &icc_bus_type;
+ iccd->dev.parent = iccm->dev;
+ iccd->dev.release = icc_lun_release;
+ iccd->dev.of_node = np;
+ iccd->iccm = iccm;
+ iccd->lun_number = reg;
+
+ /* TODO use device_create? to move major/minor registration here? */
+ ret = device_register(&iccd->dev);
+ if (ret < 0) {
+ dev_warn(iccm->dev, "filed to registr lun %i\n", reg);
+ put_device(&iccd->dev);
+ }
+
+ iccd->configured = true;
+
+ return 0;
+}
+
+static void icc_add_luns_from_dt(struct icc_master *iccm)
+{
+ struct device_node *np = iccm->dev->of_node;
+ struct device_node *child;
+
+ for_each_available_child_of_node(np, child)
+ icc_add_lun_from_dt(iccm, child);
+
+}
+
+void icc_add_luns(struct icc_master *iccm)
+{
+ iccm->icc_class = icc_class;
+ icc_add_luns_from_dt(iccm);
+}
+EXPORT_SYMBOL_GPL(icc_add_luns);
+
+static int __init icc_bus_init(void)
+{
+ int ret;
+
+ icc_class = class_create(THIS_MODULE, "icc");
+ if (IS_ERR(icc_class)) {
+ ret = PTR_ERR(icc_class);
+ return ret;
+ }
+
+ return bus_register(&icc_bus_type);
+}
+postcore_initcall(icc_bus_init);
+
+static void __exit icc_bus_exit(void)
+{
+ class_destroy(icc_class);
+ bus_unregister(&icc_bus_type);
+}
+module_exit(icc_bus_exit);
+
+MODULE_AUTHOR("Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>");
+MODULE_DESCRIPTION("ICC framework");
+MODULE_LICENSE("GPL");
+
diff --git a/drivers/icc/ssi32/Kconfig b/drivers/icc/ssi32/Kconfig
new file mode 100644
index 0000000..e22c322
--- /dev/null
+++ b/drivers/icc/ssi32/Kconfig
@@ -0,0 +1,12 @@
+#
+# Incnet protocol
+#
+
+config ICC_SSI32
+ tristate "SSI32 (EXPERIMENTAL)"
+ depends on ICC
+ depends on OF
+ depends on SPI
+ ---help---
+ To compile this driver as a module, choose M here: the module
+ will be called SSI32.
diff --git a/drivers/icc/ssi32/Makefile b/drivers/icc/ssi32/Makefile
new file mode 100644
index 0000000..5fdeaed
--- /dev/null
+++ b/drivers/icc/ssi32/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for SSI32 support code.
+#
+
+icc_ssi32-y := ssi32_spi_hif.o ssi32_prot.o
+obj-$(CONFIG_ICC_SSI32) += icc_ssi32.o
diff --git a/drivers/icc/ssi32/ssi32_prot.c b/drivers/icc/ssi32/ssi32_prot.c
new file mode 100644
index 0000000..31ee5fb
--- /dev/null
+++ b/drivers/icc/ssi32/ssi32_prot.c
@@ -0,0 +1,256 @@
+/*
+ * Copyright (C) 2016 Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/debugfs.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/proc_fs.h>
+#include <linux/slab.h>
+#include <linux/spi/spi.h>
+#include <linux/pm_runtime.h>
+#include <linux/icc/ssi32.h>
+#include <linux/icc/icc.h>
+
+#include "ssi32_spi_hif.h"
+
+/* Proper name? alloc? */
+int ssi32_trf_init(struct ssi32_prot_priv *ssi32pp,
+ struct ssi32_prot_trf *trf, u8 lun, size_t data_size)
+{
+ struct ssi32_prot_hdr *hdr;
+
+ trf->buf = devm_kzalloc(ssi32pp->dev, ssi32pp->trf_size,
+ GFP_KERNEL);
+ if (!trf->buf)
+ return -ENOMEM;
+
+ trf->hdr = trf->buf;
+ trf->data = trf->buf + SSI32_HDR_SIZE;
+ trf->data_size = data_size;
+ trf->size = data_size + SSI32_HDR_SIZE;
+
+ hdr = trf->hdr;
+ hdr->lun = lun;
+
+ return 0;
+}
+
+void ssi32_trf_free(struct ssi32_prot_priv *ssi32pp,
+ struct ssi32_prot_trf *trf)
+{
+ devm_kfree(ssi32pp->dev, trf->buf);
+}
+
+static unsigned char ssi32_chksum(void *data, size_t len)
+{
+ u32 sum = 0;
+ unsigned int i;
+ u8 *buf = data;
+
+ for (i = 0; i < len; i++)
+ sum += buf[i];
+ /* return 2's complement */
+ return (u8)((~sum) + 1);
+}
+
+static void *ssi32_setup_tx_buf(struct ssi32_prot_priv *ssi32pp,
+ struct ssi32_prot_trf *tx_trf)
+{
+ struct ssi32_prot_hdr *tx_hdr = tx_trf->hdr;
+
+ if (unlikely(tx_trf->size > ssi32pp->trf_size)) {
+ dev_warn(ssi32pp->dev, "tx size is to big: %i > %i\n",
+ tx_trf->size, ssi32pp->trf_size);
+ return NULL;
+ }
+
+ tx_hdr->ctrl = SSI32_CTRL_DEFAULT;
+ tx_hdr->dlc = tx_trf->data_size;
+
+ if (!tx_hdr->dlc)
+ tx_hdr->ctrl |= SSI32_CTRL_NO_MSG;
+ else if (tx_trf->data_size < tx_trf->size)
+ memset(tx_trf->data + tx_trf->data_size, 0,
+ tx_trf->size - tx_trf->data_size);
+
+ tx_hdr->chk = 0;
+ tx_hdr->chk = ssi32_chksum(tx_trf->buf, tx_trf->size);
+
+ return tx_trf->buf;
+}
+
+static void ssi32_setup_tx_ack(struct ssi32_prot_ack *ack, u32 err)
+{
+ memset(ack, 0, sizeof(*ack));
+ ack->tx_ack = SSI32_ACK_DEFAULT;
+
+ if (!(err & SSI32_RX_ERR_MASK)) {
+ ack->tx_ack |= SSI32_ACK_POS_ACK;
+ return;
+ }
+
+ if (err & SSI32_RX_CHK_ERR)
+ ack->tx_ack |= SSI32_ACK_CHK_ERR;
+ if (err & SSI32_RX_SEQ_ERR)
+ ack->tx_ack |= SSI32_ACK_SEQ_ERR;
+ if (err & SSI32_RX_SYN_ERR)
+ ack->tx_ack |= SSI32_ACK_CHK_ERR;
+ if (err & SSI32_RX_XOFF_ERR)
+ ack->tx_ack |= SSI32_ACK_XOFF;
+}
+
+static int ssi32_process_ack(struct ssi32_prot_ack *ack)
+{
+ return 0;
+}
+
+static u32 ssi32_process_rx(struct ssi32_prot_priv *ssi32pp)
+{
+ struct ssi32_prot_hdr *rx_hdr = ssi32pp->rx_buf;
+ struct icc_master *iccm = &ssi32pp->iccm;
+ struct icc_device *iccd;
+ size_t rx_size;
+ int ret;
+
+ rx_size = rx_hdr->dlc + SSI32_HDR_SIZE;
+ if (rx_size > ssi32pp->trf_size) {
+ dev_dbg(ssi32pp->dev, "rx size is wrong %i\n", rx_size);
+ return SSI32_RX_CHK_ERR;
+ }
+
+ if (ssi32_chksum(ssi32pp->rx_buf, rx_size)) {
+ dev_dbg(ssi32pp->dev, "rx chksum err\n");
+ return SSI32_RX_CHK_ERR;
+ }
+
+ /* got dummy message */
+ if (rx_hdr->lun == SSI32_MAX_LUNS)
+ return 0;
+
+ iccd = &iccm->lun[rx_hdr->lun];
+ if (!iccd->rx_cb)
+ return SSI32_RX_XOFF_ERR;
+
+ ret = iccd->rx_cb(iccd, ssi32pp->rx_buf + SSI32_HDR_SIZE,
+ rx_hdr->dlc);
+
+ /* what is better error here? */
+ if (ret == -EBUSY)
+ return SSI32_RX_CHK_ERR;
+
+ return ret;
+}
+
+int ssi32_prot_shift(struct ssi32_prot_priv *ssi32pp,
+ struct ssi32_prot_trf *tx_trf)
+{
+ void *tx_buf = NULL;
+ u32 err = 0;
+ int ret;
+
+ ssi32_hif_idle(ssi32pp->hif, false);
+
+ if (!tx_trf)
+ tx_trf = &ssi32pp->tx_dummy_trf;
+
+ if (tx_trf) {
+ tx_buf = ssi32_setup_tx_buf(ssi32pp, tx_trf);
+ if (!tx_buf)
+ return -ENOMEM;
+ }
+
+ ret = ssi32_shift_one_msg(ssi32pp->hif, tx_buf,
+ ssi32pp->rx_buf, ssi32pp->trf_size);
+ if (ret)
+ return ret;
+
+ err = ssi32_process_rx(ssi32pp);
+
+ ssi32_setup_tx_ack(&ssi32pp->tx_ack, err);
+
+ ret = ssi32_shift_one_msg(ssi32pp->hif, &ssi32pp->tx_ack,
+ &ssi32pp->rx_ack, SSI32_ACK_SIZE);
+ if (ret)
+ return ret;
+
+ ret = ssi32_process_ack(&ssi32pp->rx_ack);
+
+ ssi32_hif_idle(ssi32pp->hif, true);
+
+ return ret;
+}
+
+static int ssi32_trf_alloc(struct icc_master *iccm,
+ struct icc_trf *tx_trf,
+ u8 lun, size_t data_size)
+{
+ struct ssi32_prot_priv *ssi32pp =
+ container_of(iccm, struct ssi32_prot_priv, iccm);
+
+ /* TODO currently struct icc_trf is identical to struct ssi32_prot_trf */
+ return ssi32_trf_init(ssi32pp, (struct ssi32_prot_trf *)tx_trf, lun, data_size);
+}
+
+static int ssi32_trf_xmit(struct icc_master *iccm,
+ struct icc_trf *tx_trf)
+{
+ struct ssi32_prot_priv *ssi32pp =
+ container_of(iccm, struct ssi32_prot_priv, iccm);
+ int ret;
+
+ mutex_lock(&ssi32pp->lock);
+ /* currently struct icc_trf is identical to struct ssi32_prot_trf */
+ ret = ssi32_prot_shift(ssi32pp, (struct ssi32_prot_trf *)tx_trf);
+ mutex_unlock(&ssi32pp->lock);
+
+ return ret;
+}
+
+int ssi32_prot_init(struct ssi32_spi_hif_priv *priv)
+{
+ struct spi_device *spi = priv->spi;
+ struct ssi32_prot_priv *ssi32pp = &priv->ssi32pp;
+ struct icc_master *iccm = &ssi32pp->iccm;
+ int ret;
+
+ iccm->dev = &spi->dev;
+ ssi32pp->dev = &spi->dev;
+ ssi32pp->hif = priv;
+
+ mutex_init(&ssi32pp->lock);
+
+ ssi32pp->trf_size = SSI32_MAX_TRANSFER_SIZE;
+ iccm->max_data_size = ssi32pp->trf_size - SSI32_HDR_SIZE;
+ ssi32pp->rx_buf = devm_kzalloc(&spi->dev, ssi32pp->trf_size * 2,
+ GFP_KERNEL);
+ iccm->trf_xmit = ssi32_trf_xmit;
+ iccm->trf_alloc = ssi32_trf_alloc;
+
+ ret = ssi32_trf_init(ssi32pp, &ssi32pp->tx_dummy_trf,
+ SSI32_MAX_LUNS, 0);
+ if (ret)
+ return ret;
+
+ icc_add_luns(iccm);
+
+ ssi32_hif_idle(ssi32pp->hif, true);
+
+ return 0;
+}
+
+void ssi32_prot_uninit(struct ssi32_spi_hif_priv *priv)
+{
+}
diff --git a/drivers/icc/ssi32/ssi32_prot.h b/drivers/icc/ssi32/ssi32_prot.h
new file mode 100644
index 0000000..fc39449
--- /dev/null
+++ b/drivers/icc/ssi32/ssi32_prot.h
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2016 Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#ifndef SSI32_PROT_H
+#define SSI32_PROT_H
+
+#include <linux/icc/ssi32.h>
+#include <linux/icc/icc.h>
+
+#define SSI32_MAX_TRANSFER_SIZE 128
+
+#define SSI32_CTRL_FIXED2 BIT(7)
+#define SSI32_CTRL_VER BIT(6)
+#define SSI32_CTRL_FIXED1 BIT(5)
+/* no message */
+#define SSI32_CTRL_NO_MSG BIT(4)
+#define SSI32_CTRL_SN BIT(3)
+/* retry message */
+#define SSI32_CTRL_RTR BIT(2)
+/* end of message */
+#define SSI32_CTRL_EOM BIT(1)
+/* start of message */
+#define SSI32_CTRL_SOM BIT(0)
+
+
+#define SSI32_CTRL_DEFAULT (SSI32_CTRL_VER | SSI32_CTRL_SOM | SSI32_CTRL_EOM)
+
+#define SSI32_RX_CHK_ERR BIT(3)
+#define SSI32_RX_SEQ_ERR BIT(2)
+#define SSI32_RX_SYN_ERR BIT(1)
+#define SSI32_RX_XOFF_ERR BIT(0)
+#define SSI32_RX_ERR_MASK (SSI32_RX_XOFF_ERR | SSI32_RX_SYN_ERR \
+ | SSI32_RX_SEQ_ERR | SSI32_RX_CHK_ERR)
+
+#define SSI32_ACK_RESERVED3 BIT(7)
+#define SSI32_ACK_RESERVED2 BIT(6)
+#define SSI32_ACK_PARITY BIT(5)
+#define SSI32_ACK_POS_ACK BIT(4)
+#define SSI32_ACK_XOFF BIT(3)
+#define SSI32_ACK_RESERVED1 BIT(2)
+#define SSI32_ACK_SEQ_ERR BIT(1)
+#define SSI32_ACK_CHK_ERR BIT(0)
+
+#define SSI32_ACK_DEFAULT (SSI32_ACK_RESERVED2 | SSI32_ACK_RESERVED3)
+#define SSI_ACKBLOCK_CHKMASK (0xffffff00 | (SSI32_ACK_RESERVED1 \
+ | SSI32_ACK_RESERVED2 | SSI32_ACK_RESERVED3))
+
+struct ssi32_prot_test {
+ struct mutex lock; /* protect from simultaneous accesses */
+ struct device *dev;
+ struct task_struct *task;
+ wait_queue_head_t wait;
+
+ struct completion input;
+ atomic_t active_rq;
+ atomic_t buffs;
+ struct ssi32_prot_trf trf;
+
+ bool dir_in;
+ size_t data_size;
+};
+
+/* ssi32 protocol struct */
+struct ssi32_prot_priv {
+ struct icc_master iccm;
+ struct ssi32_spi_hif_priv *hif;
+ struct mutex lock; /* protect from simultaneous accesses */
+ struct device *dev;
+ struct task_struct *task;
+ wait_queue_head_t wait;
+
+ struct completion input;
+ atomic_t active_rq;
+
+ struct ssi32_prot_ack tx_ack;
+ struct ssi32_prot_ack rx_ack;
+
+ size_t trf_size;
+ void *rx_buf;
+ struct ssi32_prot_trf tx_dummy_trf;
+
+ struct ssi32_prot_test test;
+};
+
+int ssi32_prot_shift(struct ssi32_prot_priv *ssi32pp,
+ struct ssi32_prot_trf *tx_trf);
+#endif /* SSI32_PROT_H */
diff --git a/drivers/icc/ssi32/ssi32_spi_hif.c b/drivers/icc/ssi32/ssi32_spi_hif.c
new file mode 100644
index 0000000..33fea82
--- /dev/null
+++ b/drivers/icc/ssi32/ssi32_spi_hif.c
@@ -0,0 +1,300 @@
+/*
+ * Copyright (C) 2016 Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/debugfs.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/proc_fs.h>
+#include <linux/slab.h>
+#include <linux/spi/spi.h>
+#include <linux/pm_runtime.h>
+
+#include "ssi32_spi_hif.h"
+
+#define DRIVER_NAME "ssi32_spi_hif"
+
+static struct dentry *debugfs_root;
+
+static irqreturn_t spi_fc_rq_thread(int irq, void *dev_id)
+{
+ struct ssi32_spi_hif_priv *priv = (struct ssi32_spi_hif_priv *)dev_id;
+ struct ssi32_prot_priv *ssi32pp = &priv->ssi32pp;
+
+ mutex_lock(&ssi32pp->lock);
+ /*
+ * slave requeste a transver, it can be processed
+ * if we wish to TX some thing or do RX only transaction.
+ */
+ if (atomic_read(&priv->active_rq))
+ ssi32_prot_shift(ssi32pp, NULL);
+ mutex_unlock(&ssi32pp->lock);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t spi_fc_rq(int irq, void *dev_id)
+{
+ struct ssi32_spi_hif_priv *priv = (struct ssi32_spi_hif_priv *)dev_id;
+ int fc_active;
+
+ fc_active = gpiod_get_value(priv->fc_gpio);
+ if (atomic_read(&priv->idle) && fc_active) {
+ atomic_set(&priv->active_rq, 1);
+ return IRQ_WAKE_THREAD;
+ }
+
+ complete(&priv->fc_complete);
+
+ return IRQ_HANDLED;
+}
+
+void ssi32_hif_idle(struct ssi32_spi_hif_priv *priv, bool idle)
+{
+
+ atomic_set(&priv->active_rq, !idle);
+ atomic_set(&priv->idle, idle);
+
+ if (idle && gpiod_get_value(priv->fc_gpio)) {
+ atomic_set(&priv->active_rq, 1);
+ irq_wake_thread(priv->fc_irq, priv);
+ }
+}
+
+/* Wait for flow control */
+static inline int ssi32_hif_wait_fc(struct ssi32_spi_hif_priv *priv,
+ bool fc_enabled)
+{
+ int ret, val;
+ int count = 8;
+
+ /* try to poll the FC line. It will allow us to speed up the response */
+ while (count) {
+ /*
+ * the switch from SLAVE_FC to SLAVE_REQ can be wary short.
+ * make sure we didn't missed it.
+ */
+ if (try_wait_for_completion(&priv->fc_complete))
+ return 0;
+
+ /*
+ * Some rounds of polling for SLAVE_FC are still faster then
+ * wait_for_completion.
+ */
+ val = gpiod_get_value(priv->fc_gpio);
+ if (val == fc_enabled)
+ return 0;
+ count--;
+ usleep_range(10, 20);
+ }
+
+ /* now we are getting slow */
+ ret = wait_for_completion_interruptible_timeout(&priv->fc_complete,
+ msecs_to_jiffies(20));
+ if (!ret)
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+int ssi32_shift_one_msg(struct ssi32_spi_hif_priv *priv,
+ void *tx_buf, void *rx_buf, size_t len)
+{
+ struct spi_device *spi = priv->spi;
+ struct spi_message m;
+ int ret = 0;
+ struct spi_transfer t = {
+ .len = 0,
+ .cs_change = 1,
+ };
+
+ /* prepare dummy message */
+ spi_message_init(&m);
+ spi_message_add_tail(&t, &m);
+
+ spi_bus_lock(spi->master);
+
+ /* send dummy to trigger CS */
+ reinit_completion(&priv->fc_complete);
+ spi_sync_locked(spi, &m);
+ ret = ssi32_hif_wait_fc(priv, true);
+ if (ret) {
+ /* recover the CS line and unlock the bus */
+ t.cs_change = 0;
+ spi_sync_locked(spi, &m);
+ dev_warn(&spi->dev, "FC failed, not Ready\n");
+ spi_bus_unlock(spi->master);
+ return ret;
+ }
+
+ /* prepare actual message */
+ t.tx_buf = tx_buf;
+ t.rx_buf = rx_buf;
+ t.len = len;
+ t.delay_usecs = 0;
+ t.cs_change = 0;
+
+ spi_message_init(&m);
+ spi_message_add_tail(&t, &m);
+
+ /*
+ * Using sync variant. according to my test, async is slower:
+ * sync - 1m2.203s for 100000 packets
+ * async - 1m14.416s for 100000 packets
+ */
+ reinit_completion(&priv->fc_complete);
+ spi_sync_locked(spi, &m);
+ ret = ssi32_hif_wait_fc(priv, false);
+ if (ret)
+ dev_warn(&spi->dev, "FC failed, no ACK\n");
+ spi_bus_unlock(spi->master);
+ return ret;
+}
+
+/* send dummy to trigger CS */
+static void ssi32_shift_dummy_msg(struct ssi32_spi_hif_priv *priv)
+{
+ struct spi_device *spi = priv->spi;
+ struct spi_message m;
+ struct spi_transfer t = {
+ .len = 0,
+ .cs_change = 0,
+ };
+
+ reinit_completion(&priv->fc_complete);
+ /* prepare dummy message */
+ spi_message_init(&m);
+ spi_message_add_tail(&t, &m);
+
+ spi_bus_lock(spi->master);
+
+ spi_sync_locked(spi, &m);
+
+ spi_bus_unlock(spi->master);
+}
+
+static int ssi32_spi_hif_probe(struct spi_device *spi)
+{
+ struct ssi32_spi_hif_priv *priv;
+ int ret;
+
+ spi->bits_per_word = 8;
+
+ ret = spi_setup(spi);
+ if (ret < 0)
+ return ret;
+
+ priv = devm_kzalloc(&spi->dev, sizeof(struct ssi32_spi_hif_priv),
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ mutex_init(&priv->lock);
+ init_completion(&priv->fc_complete);
+ init_completion(&priv->input);
+ init_waitqueue_head(&priv->wait);
+
+ spi_set_drvdata(spi, priv);
+
+ priv->spi = spi;
+ spi->master->rt = 1;
+
+ priv->fc_gpio = devm_gpiod_get(&spi->dev, "fc", GPIOD_IN);
+ if (IS_ERR(priv->fc_gpio)) {
+ ret = PTR_ERR(priv->fc_gpio);
+ dev_err(&spi->dev, "Failed to request FC GPIO: %d\n", ret);
+ return ret;
+ }
+
+ priv->fc_irq = gpiod_to_irq(priv->fc_gpio);
+ if (priv->fc_irq < 0) {
+ dev_err(&spi->dev, "Can't registr IRQ for GPIO\n");
+ return priv->fc_irq;
+ }
+
+ ret = devm_request_threaded_irq(&spi->dev, priv->fc_irq, spi_fc_rq,
+ spi_fc_rq_thread, IRQF_TRIGGER_RISING
+ | IRQF_TRIGGER_FALLING,
+ dev_name(&spi->dev), priv);
+ if (ret) {
+ dev_err(&spi->dev, "Failed to request FC IRQ\n");
+ return ret;
+ }
+
+ priv->debugfs = debugfs_create_dir(dev_name(&spi->dev), debugfs_root);
+
+ pm_runtime_forbid(spi->master->dev.parent);
+ /*
+ * Shift a dummy packet to prepare the SPI Master. For example
+ * set CS to proper state. FIXME: should it be fixed in SPI framework?
+ */
+ ssi32_shift_dummy_msg(priv);
+
+ return ssi32_prot_init(priv);
+}
+
+static int ssi32_spi_hif_remove(struct spi_device *spi)
+{
+ struct ssi32_spi_hif_priv *priv = spi_get_drvdata(spi);
+
+ ssi32_prot_uninit(priv);
+
+ pm_runtime_allow(spi->master->dev.parent);
+ if (!priv)
+ return -ENODEV;
+
+ mutex_destroy(&priv->lock);
+
+ return 0;
+}
+
+static const struct of_device_id ssi32_spi_hif_match[] = {
+ {
+ .compatible = "rbcm,icc-ssi32",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ssi32_spi_hif_match);
+
+static struct spi_driver ssi32_spi_hif_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(ssi32_spi_hif_match),
+ },
+ .probe = ssi32_spi_hif_probe,
+ .remove = ssi32_spi_hif_remove,
+};
+
+static int __init ssi32_spi_hif_init(void)
+{
+ debugfs_root = debugfs_create_dir(DRIVER_NAME, NULL);
+ if (IS_ERR_OR_NULL(debugfs_root)) {
+ pr_err("%s: Filed to create debufs entry.\n", DRIVER_NAME);
+ return -ENOMEM;
+ }
+
+ return spi_register_driver(&ssi32_spi_hif_driver);
+}
+subsys_initcall(ssi32_spi_hif_init);
+
+static void __exit ssi32_spi_hif_exit(void)
+{
+ debugfs_remove_recursive(debugfs_root);
+ spi_unregister_driver(&ssi32_spi_hif_driver);
+}
+module_exit(ssi32_spi_hif_exit);
+
+MODULE_AUTHOR("Oleksij Rempel <linux@rempel-privat.de>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/icc/ssi32/ssi32_spi_hif.h b/drivers/icc/ssi32/ssi32_spi_hif.h
new file mode 100644
index 0000000..bf51a58
--- /dev/null
+++ b/drivers/icc/ssi32/ssi32_spi_hif.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2016 Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#ifndef SSI32_SPI_HIF_H
+#define SSI32_SPI_HIF_H
+
+#include "ssi32_prot.h"
+
+struct ssi32_spi_hif_priv {
+ struct mutex lock; /* protect from simultaneous accesses */
+ u8 port_config;
+ struct spi_device *spi;
+ struct gpio_desc *fc_gpio;
+ int fc_irq;
+ struct dentry *debugfs;
+ struct completion fc_complete;
+ struct completion input;
+ atomic_t active_rq;
+ atomic_t idle;
+ struct task_struct *task;
+ wait_queue_head_t wait;
+
+ struct ssi32_prot_priv ssi32pp;
+};
+
+void ssi32_hif_idle(struct ssi32_spi_hif_priv *priv, bool idle);
+int ssi32_shift_one_msg(struct ssi32_spi_hif_priv *priv,
+ void *tx_buf, void *rx_buf, size_t len);
+
+int ssi32_prot_init(struct ssi32_spi_hif_priv *priv);
+void ssi32_prot_uninit(struct ssi32_spi_hif_priv *priv);
+
+#endif /* SSI32_H */
diff --git a/include/linux/icc/icc.h b/include/linux/icc/icc.h
new file mode 100644
index 0000000..e0b93e6
--- /dev/null
+++ b/include/linux/icc/icc.h
@@ -0,0 +1,88 @@
+#ifndef _ICC_CORE_H_
+#define _ICC_CORE_H_
+
+#include <linux/device.h>
+
+#define ICC_MAX_LUNS 255
+
+struct icc_trf;
+struct icc_master;
+
+struct icc_device {
+ struct device dev;
+ struct icc_master *iccm;
+ void *data;
+ bool configured;
+ unsigned int lun_number;
+
+ int (*rx_cb)(struct icc_device *, void *, size_t);
+};
+
+struct icc_master {
+ struct device *dev;
+ struct class *icc_class;
+ int max_data_size;
+
+ int (*trf_alloc)(struct icc_master *, struct icc_trf *, u8, size_t);
+ int (*trf_xmit)(struct icc_master *, struct icc_trf *);
+
+ struct icc_device lun[ICC_MAX_LUNS];
+};
+
+struct icc_driver {
+ struct device_driver driver;
+ int (*probe)(struct icc_device *);
+ int (*remove)(struct icc_device *);
+ void (*shutdown)(struct icc_device *);
+};
+
+struct icc_trf {
+ void *buf;
+ void *hdr;
+ void *data;
+ size_t size;
+ size_t data_size;
+};
+
+static inline struct icc_device *to_icc_device(struct device *dev)
+{
+ return dev ? container_of(dev, struct icc_device, dev) : NULL;
+}
+
+static inline struct icc_driver *to_icc_driver(struct device_driver *drv)
+{
+ return drv ? container_of(drv, struct icc_driver, driver) : NULL;
+}
+
+static inline void icc_set_drvdata(struct icc_device *iccd, void *data)
+{
+ dev_set_drvdata(&iccd->dev, data);
+}
+
+static inline void *icc_get_drvdata(struct icc_device *iccd)
+{
+ return dev_get_drvdata(&iccd->dev);
+}
+
+static inline void icc_set_rxcb(struct icc_device *iccd,
+ int (*rx_cb)(struct icc_device *, void *, size_t))
+{
+ iccd->rx_cb = rx_cb;
+}
+
+static inline int icc_trf_alloc(struct icc_master *iccm,
+ struct icc_trf *trf, u8 lun, size_t size)
+{
+ return iccm->trf_alloc(iccm, trf, lun, size);
+}
+static inline int icc_trf_xmit(struct icc_master *iccm,
+ struct icc_trf *trf)
+{
+ return iccm->trf_xmit(iccm, trf);
+}
+
+int icc_register_driver(struct icc_driver *);
+void icc_unregister_driver(struct icc_driver *);
+void icc_add_luns(struct icc_master *iccm);
+
+#endif /* _ICC_CORE_H_ */
diff --git a/include/linux/icc/ssi32.h b/include/linux/icc/ssi32.h
new file mode 100644
index 0000000..8015c21e
--- /dev/null
+++ b/include/linux/icc/ssi32.h
@@ -0,0 +1,32 @@
+#ifndef _SSI32_CORE_H_
+#define _SSI32_CORE_H_
+
+#include <linux/device.h>
+
+#define SSI32_MAX_LUNS 255
+
+#define SSI32_HDR_SIZE 4
+struct ssi32_prot_hdr {
+ u8 ctrl;
+ u8 lun;
+ u8 dlc;
+ u8 chk;
+} __packed;
+
+#define SSI32_ACK_SIZE 4
+struct ssi32_prot_ack {
+ u8 tx_ack;
+ u8 reserved0;
+ u8 reserved1;
+ u8 reserved2;
+} __packed;
+
+struct ssi32_prot_trf {
+ void *buf;
+ struct ssi32_prot_hdr *hdr;
+ void *data;
+ size_t size;
+ size_t data_size;
+};
+
+#endif /* _SSI32_H_ */
--
1.9.1
^ permalink raw reply related
* [RFC 2/3] watchdog: add icc watchdog driver
From: fixed-term.Oleksij.Rempel @ 2016-11-09 6:04 UTC (permalink / raw)
To: linux-kernel, linux-soc, dirk.behme, mkl; +Cc: Oleksij Rempel, Oleksij Rempel
In-Reply-To: <1478671461-25135-1-git-send-email-fixed-term.Oleksij.Rempel@de.bosch.com>
From: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
this driver is needed to ping over ICC bus a watchdog.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
---
drivers/watchdog/Kconfig | 8 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/icc_wdt.c | 185 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 194 insertions(+)
create mode 100644 drivers/watchdog/icc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 16f2023..7e52835 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -104,6 +104,14 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config ICC_WATCHDOG
+ tristate "ICC watchdog"
+ depends on ICC
+ select WATCHDOG_CORE
+ help
+ If you say yes here you get support for watchdog device
+ controlled through ICC bus.
+
config MENF21BMC_WATCHDOG
tristate "MEN 14F021P00 BMC Watchdog"
depends on MFD_MENF21BMC
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c19294..40451cc 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -181,6 +181,7 @@ obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9063_WATCHDOG) += da9063_wdt.o
obj-$(CONFIG_GPIO_WATCHDOG) += gpio_wdt.o
+obj-$(CONFIG_ICC_WATCHDOG) += icc_wdt.o
obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
diff --git a/drivers/watchdog/icc_wdt.c b/drivers/watchdog/icc_wdt.c
new file mode 100644
index 0000000..a89dc15
--- /dev/null
+++ b/drivers/watchdog/icc_wdt.c
@@ -0,0 +1,185 @@
+/*
+ * Driver for RBCM INC Gen3 Watchdog.
+ * RBCM - Robert Bosch Car Multimedia GmbH
+ * INC - Inter node communication.
+ * Gen3 - Generation 3 products.
+ * Short: rig3 :)
+ *
+ * Copyright (C) Robert Bosch Car Multimedia GmbH
+ * Authors:
+ * Oleksij Rempel
+ * <fixed-term.Oleksij.Rempel@de.bosch.com>
+ * <linux@rempel-privat.de>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reboot.h>
+#include <linux/reset.h>
+#include <linux/watchdog.h>
+#include <linux/icc/icc.h>
+
+struct icc_wdt_priv {
+ struct device *dev;
+ struct icc_device *iccd;
+ struct watchdog_device wdd;
+
+ struct icc_trf trf;
+ bool check_pong;
+ atomic_t pong;
+};
+
+static int icc_wdt_feed(struct watchdog_device *wdd)
+{
+ struct icc_wdt_priv *priv = watchdog_get_drvdata(wdd);
+ struct icc_device *iccd = priv->iccd;
+
+ if (priv->check_pong && atomic_read(&priv->pong))
+ dev_warn_ratelimited(priv->dev, "making ping without getting pong\n");
+
+ atomic_set(&priv->pong, 1);
+
+ return icc_trf_xmit(iccd->iccm, &priv->trf);
+}
+
+static int icc_wdt_enable(struct watchdog_device *wdd)
+{
+ return 0;
+}
+
+static int icc_wdt_stop(struct watchdog_device *wdd)
+{
+ return 0;
+}
+
+static const struct watchdog_info icc_wdt_ident = {
+ .identity = "RBCM, Inc Gen3 WatchDog",
+};
+
+static struct watchdog_ops icc_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = icc_wdt_enable,
+ .stop = icc_wdt_stop,
+ .ping = icc_wdt_feed,
+};
+
+static int icc_wdt_rx_cb(struct icc_device *iccd, void *rx_buf, size_t size)
+{
+ struct icc_wdt_priv *priv = icc_get_drvdata(iccd);
+
+ atomic_set(&priv->pong, 0);
+
+ return 0;
+}
+
+static int icc_wdt_int_trf(struct icc_wdt_priv *priv)
+{
+ struct icc_device *iccd = priv->iccd;
+ struct icc_trf *trf = &priv->trf;
+
+ u8 *buf;
+ int ret;
+
+ ret = icc_trf_alloc(iccd->iccm, trf, 9, 1);
+ if (ret)
+ return ret;
+
+ buf = trf->data;
+ buf[0] = 0x62;
+
+ return 0;
+}
+
+static int icc_wdt_probe(struct icc_device *iccd)
+{
+ struct device *dev = &iccd->dev;
+ struct icc_wdt_priv *priv;
+ struct watchdog_device *wdd;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(struct icc_wdt_priv),
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ priv->iccd = iccd;
+
+ wdd = &priv->wdd;
+ wdd->info = &icc_wdt_ident;
+ wdd->ops = &icc_wdt_ops;
+ wdd->min_timeout = 1;
+ wdd->max_timeout = 10;
+ wdd->parent = dev;
+
+ icc_set_drvdata(iccd, priv);
+ icc_set_rxcb(iccd, icc_wdt_rx_cb);
+ watchdog_set_drvdata(wdd, priv);
+
+ /*
+ * If 'timeout-sec' unspecified in devicetree, assume a 30 second
+ * default, unless the max timeout is less than 30 seconds, then use
+ * the max instead.
+ */
+ watchdog_init_timeout(wdd, 10, dev);
+
+ ret = watchdog_register_device(wdd);
+ if (ret)
+ return ret;
+
+ ret = icc_wdt_int_trf(priv);
+ if (ret)
+ return ret;
+
+ dev_info(dev, "Watchdog enabled\n");
+ return 0;
+}
+
+static int icc_wdt_remove(struct icc_device *iccd)
+{
+ struct icc_wdt_priv *priv = icc_get_drvdata(iccd);
+
+ watchdog_unregister_device(&priv->wdd);
+
+ return 0;
+}
+
+static const struct of_device_id icc_wdt_of_match[] = {
+ { .compatible = "rbcm,inc-wdt-gen3" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, icc_wdt_of_match);
+
+static struct icc_driver icc_wdt_driver = {
+ .driver = {
+ .name = "inc-wdt-gen3",
+ .owner = THIS_MODULE,
+ .of_match_table = icc_wdt_of_match,
+ },
+ .probe = icc_wdt_probe,
+ .remove = icc_wdt_remove,
+};
+
+static int __init icc_wdt_init(void)
+{
+ return icc_register_driver(&icc_wdt_driver);
+}
+module_init(icc_wdt_init);
+
+static void __exit icc_wdt_exit(void)
+{
+ icc_unregister_driver(&icc_wdt_driver);
+}
+module_exit(icc_wdt_exit);
+
+MODULE_DESCRIPTION("ICC WatchDog Driver");
+MODULE_AUTHOR("Oleksij Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [RFC 0/3] add Inter Chip Communication framework
From: fixed-term.Oleksij.Rempel @ 2016-11-09 6:04 UTC (permalink / raw)
To: linux-kernel, linux-soc, dirk.behme, mkl; +Cc: Oleksij Rempel
From: Oleksij Rempel <linux@rempel-privat.de>
Hallo all,
i'm working on upstreamable version of ICC (Inter Chip Communication)
framework. It is used to provide kernel level abstraction for functionality
located in neighbor SoC or MCU.
The idea is not really different from existing driver/hsi, but currently it
seems to be painful to rework it to fit our needs.
The structure of ICC is fallowing:
- transport level: currently only SSI32 (based on SPI) is provided.
I can imagine that HSI (drivers/hsi) and HTC (ath9k-htc) can be placed
here too.
- icc bus: provides an upstraction level for icc clients
- icc clients. Drivers for: char device, watchdog, rtc, CAN, gpio.
Current patchset I a request for comments, before I'll start to bug you will
patch reviews und PRs.
Please let me know if i'm going to right or wrong direction.
Oleksij Rempel (3):
icc: add add SSI32 transport driver
watchdog: add icc watchdog driver
char: add icc_char device
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/char/Kconfig | 9 ++
drivers/char/Makefile | 1 +
drivers/char/icc_char.c | 280 +++++++++++++++++++++++++++++++++++
drivers/icc/Kconfig | 13 ++
drivers/icc/Makefile | 5 +
drivers/icc/icc_bus.c | 204 ++++++++++++++++++++++++++
drivers/icc/ssi32/Kconfig | 12 ++
drivers/icc/ssi32/Makefile | 6 +
drivers/icc/ssi32/ssi32_prot.c | 256 ++++++++++++++++++++++++++++++++
drivers/icc/ssi32/ssi32_prot.h | 94 ++++++++++++
drivers/icc/ssi32/ssi32_spi_hif.c | 300 ++++++++++++++++++++++++++++++++++++++
drivers/icc/ssi32/ssi32_spi_hif.h | 40 +++++
drivers/watchdog/Kconfig | 8 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/icc_wdt.c | 185 +++++++++++++++++++++++
include/linux/icc/icc.h | 88 +++++++++++
include/linux/icc/ssi32.h | 32 ++++
19 files changed, 1537 insertions(+)
create mode 100644 drivers/char/icc_char.c
create mode 100644 drivers/icc/Kconfig
create mode 100644 drivers/icc/Makefile
create mode 100644 drivers/icc/icc_bus.c
create mode 100644 drivers/icc/ssi32/Kconfig
create mode 100644 drivers/icc/ssi32/Makefile
create mode 100644 drivers/icc/ssi32/ssi32_prot.c
create mode 100644 drivers/icc/ssi32/ssi32_prot.h
create mode 100644 drivers/icc/ssi32/ssi32_spi_hif.c
create mode 100644 drivers/icc/ssi32/ssi32_spi_hif.h
create mode 100644 drivers/watchdog/icc_wdt.c
create mode 100644 include/linux/icc/icc.h
create mode 100644 include/linux/icc/ssi32.h
--
1.9.1
^ permalink raw reply
* [U-Boot] [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related erratum
From: Shengzhou Liu @ 2016-11-09 6:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AM4PR0401MB17323A68C5F41C2B31B7303B9AA60@AM4PR0401MB1732.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: york sun
> Sent: Wednesday, November 09, 2016 1:04 AM
> To: Shengzhou Liu <shengzhou.liu@nxp.com>; u-boot at lists.denx.de
> Subject: Re: [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related
> erratum
>
> On 11/08/2016 02:39 AM, Shengzhou Liu wrote:
> >
> >> -----Original Message-----
> >> From: york sun
> >> Sent: Tuesday, November 08, 2016 1:04 AM
> >> To: Shengzhou Liu <shengzhou.liu@nxp.com>; u-boot at lists.denx.de
> >> Subject: Re: [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean
> >> related erratum
> >>>
> >>> York,
> >>>
> >>> This change(moving to ctrl_regs.c) has the same effect as
> >>> read-modify- write(done in fsl_ddr_gen4.c) before MEM_EN is enabled
> for DDRC.
> >>> As I commented in code with "the POR value of debug_29 register is
> >>> zero" for A009942 workaround when moving it to ctrl_regs.c, Actually
> >>> only A008378 changes debug_29[8:11] bits to 9 from original POR
> >>> value 0 before the implementing of A009942, and A009942 overrides
> debug_29[8:11] set by A008378.
> >>> So we can set debug_29 in ctrl_regs.c, it doesn't break anything.
> >>
> >> Shengzhou,
> >>
> >> The presumption of POR value is not safe. It is safe for this case for now.
> >> You may have other erratum workaround popping up later using the
> same
> >> register, or other registers. PBI can also change registers. This
> >> sets an example to preset those registers out the scope of hardware
> >> interaction, regardless which controller is in use, or its state.
> >>
> >
> > York
> > This change(move to common ctrl_regs.c for reuse on DDR4/DDR3) is
> only
> > for A009942, For other erratum workaround popping up later using the
> > same register, or other registers, we still can implement them in
> fsl_ddr_gen4.c or in other according to actual specific sequence
> requirement.
> > I will add reading value of debug_29 register for A009942 in ctrl_regs.c in
> next version, which will be safe regardless how POR changes.
>
> You added A009942 and A008378. I don't think this is the right way. You
> break the isolation between calculating the register values and hardware
> interface. If you follow this path, you will add more and more hardware
> interaction into ctrl_regs.c file. Until your change you don't have to worry
> about any hardware condition in this file.
>
If we keep A009942 workaround in fsl_ddr_gen4.c,
1) we have to duplicate 3 same implement of A009942 separately in mpc85xx_ddr_gen3.c, arm_ddr_gen3.c and fsl_ddr_gen4.c, that is not a good idea.
2) we have to modify more code struct to introduce memctl_options_t *popts pointer in mpc85xx_ddr_gen3.c, arm_ddr_gen3.c and fsl_ddr_gen4.c to configure new option popts->cpo_sample.
You had added ERRATUM_A004508 in ctrl_regs.c instead of in hardware interface, so as a special A009942, we can do it as well.
Actually I had carefully thought of what you mentioned concerns before I decided to move A009942 and A008378(only for debug[28]) to common ctrl_regs.c. for future erratum and other registers except debug[28], we still keep them in files of hardware interface.
-Shengzhou
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] boot-serial-test: Add a test for the powernv machine
From: Cédric Le Goater @ 2016-11-09 6:00 UTC (permalink / raw)
To: David Gibson; +Cc: Thomas Huth, Alexander Graf, qemu-ppc, qemu-devel
In-Reply-To: <20161109010234.GA427@umbus.fritz.box>
On 11/09/2016 02:02 AM, David Gibson wrote:
> On Tue, Nov 08, 2016 at 02:05:35PM +0100, Cédric Le Goater wrote:
>> On 11/08/2016 01:36 PM, Thomas Huth wrote:
>>> The new powernv machine ships with a firmware that outputs
>>> some text to the serial console, so we can automatically
>>> test this machine type in the boot-serial tester, too.
>>> And to get some (very limited) test coverage for the new
>>> POWER9 CPU emulation, too, this test is also started with
>>> "-cpu POWER9".
>>
>> and we see the minimum :
>>
>> [8450016,6] CPU: P9 generation processor(max 4 threads/core)
>>
>> Reviewed-by: Cédric Le Goater <clg@kaod.org>
>>
>>
>>
>> With very minimal changes (definition of some SPRs and the use
>> of the SHV mode), the guest would load the kernel.
>
> Applied to ppc-for-2.8. Good to have this basic smoke test for
> powernv.
yes. qom-test is also starting a powernv guest.
skiboot has a cool little program called hello_kernel that can be
run in place of the real kernel, but that's beyond the qemu layer
I guess
For qemu, maybe we could do xscom accesses to test some devices.
C.
^ permalink raw reply
* Re: Question about 2 gp8psk patches I noticed, and possible bug.
From: VDR User @ 2016-11-09 6:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: mailing list: linux-media
In-Reply-To: <20161108155520.224229d5@vento.lan>
Hi Mauro,
Unfortunately the patch doesn't seem to have solved the problem. I do
have the kernel recompiled with debug enabled though per your irc msg.
dmesg gives me:
[ 70.741073] usbcore: deregistering interface driver dvb_usb_gp8psk
[ 70.741165] ------------[ cut here ]------------
[ 70.741172] WARNING: CPU: 1 PID: 2119 at kernel/module.c:1108
module_put+0x67/0x80
[ 70.741174] Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core
nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel
snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore
nvidia(PO)
[ 70.741186] CPU: 1 PID: 2119 Comm: rmmod Tainted: P O
4.8.4-build.2 #1
[ 70.741187] Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
[ 70.741189] 00000000 c12c15f0 00000000 00000000 c103fc7a c161ecc0
00000001 00000847
[ 70.741194] c161e50f 00000454 c10a4b87 c10a4b87 00000009 fb090cc0
00000000 00000000
[ 70.741197] f4e72000 c103fd43 00000009 00000000 00000000 c10a4b87
fb08f6a0 c10a58fa
[ 70.741202] Call Trace:
[ 70.741206] [<c12c15f0>] ? dump_stack+0x44/0x64
[ 70.741209] [<c103fc7a>] ? __warn+0xfa/0x120
[ 70.741211] [<c10a4b87>] ? module_put+0x67/0x80
[ 70.741213] [<c10a4b87>] ? module_put+0x67/0x80
[ 70.741215] [<c103fd43>] ? warn_slowpath_null+0x23/0x30
[ 70.741217] [<c10a4b87>] ? module_put+0x67/0x80
[ 70.741221] [<fb08f6a0>] ? gp8psk_fe_set_frontend+0x460/0x460
[dvb_usb_gp8psk]
[ 70.741223] [<c10a58fa>] ? symbol_put_addr+0x2a/0x50
[ 70.741225] [<fb08e04e>] ? gp8psk_usb_disconnect+0x4e/0x90 [dvb_usb_gp8psk]
[ 70.741229] [<c13da272>] ? usb_unbind_interface+0x62/0x250
[ 70.741233] [<c1551f3f>] ? _raw_spin_unlock_irqrestore+0xf/0x30
[ 70.741235] [<c1372ea4>] ? __pm_runtime_idle+0x44/0x70
[ 70.741239] [<c1369a68>] ? __device_release_driver+0x78/0x120
[ 70.741241] [<c136a297>] ? driver_detach+0x87/0x90
[ 70.741243] [<c13695d8>] ? bus_remove_driver+0x38/0x90
[ 70.741245] [<c13d9608>] ? usb_deregister+0x58/0xb0
[ 70.741248] [<c10a5eb0>] ? SyS_delete_module+0x130/0x1f0
[ 70.741251] [<c1036200>] ? __do_page_fault+0x1a0/0x440
[ 70.741253] [<c1000fa5>] ? exit_to_usermode_loop+0x85/0x90
[ 70.741254] [<c10013f0>] ? do_fast_syscall_32+0x80/0x130
[ 70.741257] [<c1552403>] ? sysenter_past_esp+0x40/0x6a
[ 70.741259] ---[ end trace a387b7eddb538bfb ]---
[ 70.743654] dvb-usb: Genpix SkyWalker-2 DVB-S receiver successfully
deinitialized and disconnected.
I read the Bug Hunting url but it's still not clear to me which line
from that dmesg text I should be focused on. It would suggest the
first line (dump_stack+0x44/0x64) but you pointed to
gp8psk_fe_set_frontend so I'm not sure what to do next. When I go into
gdb I see:
gdb $(find /lib/modules/$(uname -r) -name dvb-usb-gp8psk.ko)
...
Reading symbols from
/lib/modules/4.8.4-build.2/kernel/drivers/media/usb/dvb-usb/dvb-usb-gp8psk.ko...(no
debugging symbols found)...done.
(gdb)
gdb /usr/src/linux/vmlinux
...
Reading symbols from /usr/src/linux/vmlinux...done.
(gdb)
(gdb)
"No debugging symbols found" doesn't sound good, but DEBUG is enabled:
$ grep "^CONFIG_DEBUG" /usr/src/linux/.config
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_BUGVERBOSE=y
On Tue, Nov 8, 2016 at 9:55 AM, Mauro Carvalho Chehab
<mchehab@s-opensource.com> wrote:
> Em Sat, 5 Nov 2016 19:24:58 -0700
> VDR User <user.vdr@gmail.com> escreveu:
>
>> I have
>> several different Genpix devices that use the gp8psk driver and in all
>> cases the following happens when I unload it:
>>
>> [494896.234616] usbcore: deregistering interface driver dvb_usb_gp8psk
>> [494896.234712] ------------[ cut here ]------------
>> [494896.234719] WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108
>> module_put+0x57/0x70
>> [494896.234720] Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core
>> nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel
>> snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore
>> nvidia(PO) [last unloaded: rc_core]
>> [494896.234732] CPU: 1 PID: 28102 Comm: rmmod Tainted: P WC O
>> 4.8.4-build.1 #1
>> [494896.234733] Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
>> [494896.234735] 00000000 c12ba080 00000000 00000000 c103ed6a c1616014
>> 00000001 00006dc6
>> [494896.234739] c1615862 00000454 c109e8a7 c109e8a7 00000009 ffffffff
>> 00000000 f13f6a10
>> [494896.234743] f5f5a600 c103ee33 00000009 00000000 00000000 c109e8a7
>> f80ca4d0 c109f617
>> [494896.234746] Call Trace:
>> [494896.234753] [<c12ba080>] ? dump_stack+0x44/0x64
>> [494896.234756] [<c103ed6a>] ? __warn+0xfa/0x120
>> [494896.234758] [<c109e8a7>] ? module_put+0x57/0x70
>> [494896.234760] [<c109e8a7>] ? module_put+0x57/0x70
>> [494896.234762] [<c103ee33>] ? warn_slowpath_null+0x23/0x30
>> [494896.234763] [<c109e8a7>] ? module_put+0x57/0x70
>> [494896.234766] [<f80ca4d0>] ? gp8psk_fe_set_frontend+0x460/0x460
>> [dvb_usb_gp8psk]
>> [494896.234769] [<c109f617>] ? symbol_put_addr+0x27/0x50
>> [494896.234771] [<f80bc9ca>] ?
>> dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]
>> [494896.234773] [<f80bb3bf>] ? dvb_usb_exit+0x2f/0xd0 [dvb_usb]
>> [494896.234776] [<c13d03bc>] ? usb_disable_endpoint+0x7c/0xb0
>> [494896.234778] [<f80bb48a>] ? dvb_usb_device_exit+0x2a/0x50 [dvb_usb]
>> [494896.234780] [<c13d2882>] ? usb_unbind_interface+0x62/0x250
>> [494896.234782] [<c136b514>] ? __pm_runtime_idle+0x44/0x70
>> [494896.234785] [<c13620d8>] ? __device_release_driver+0x78/0x120
>> [494896.234787] [<c1362907>] ? driver_detach+0x87/0x90
>> [494896.234789] [<c1361c48>] ? bus_remove_driver+0x38/0x90
>> [494896.234791] [<c13d1c18>] ? usb_deregister+0x58/0xb0
>> [494896.234793] [<c109fbb0>] ? SyS_delete_module+0x130/0x1f0
>> [494896.234796] [<c1055654>] ? task_work_run+0x64/0x80
>> [494896.234798] [<c1000fa5>] ? exit_to_usermode_loop+0x85/0x90
>> [494896.234800] [<c10013f0>] ? do_fast_syscall_32+0x80/0x130
>> [494896.234803] [<c1549f43>] ? sysenter_past_esp+0x40/0x6a
>> [494896.234805] ---[ end trace 6ebc60ef3981792f ]---
>> [494896.235890] dvb-usb: Genpix SkyWalker-2 DVB-S receiver
>> successfully deinitialized and disconnected.
>
> I suspect that this is due to a race condition at device unregister.
> could you please try the enclosed patch?
>
> gp8psk: unregister gp8psk-fe early
>
> Letting gp8psk-fe to unregister late can cause race issues.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
>
> diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c
> index 2829e3082d15..04ea2bbbe5ae 100644
> --- a/drivers/media/usb/dvb-usb/gp8psk.c
> +++ b/drivers/media/usb/dvb-usb/gp8psk.c
> @@ -270,6 +270,32 @@ static int gp8psk_usb_probe(struct usb_interface *intf,
> return ret;
> }
>
> +static void gp8psk_usb_disconnect(struct usb_interface *intf)
> +{
> + struct dvb_usb_device *d = usb_get_intfdata(intf);
> + struct dvb_usb_adapter *adap;
> + int i, n;
> +
> + /*
> + * As gsp8psk-fe can call back this driver, in order to do URB
> + * transfers, we need to manually exit the frontend earlier.
> + */
> + for (n = 0; n < d->num_adapters_initialized; n++) {
> + adap = &d->adapter[n];
> + i = adap->num_frontends_initialized - 1;
> +
> + for (; i >= 0; i--) {
> + if (adap->fe_adap[i].fe != NULL) {
> + dvb_unregister_frontend(adap->fe_adap[i].fe);
> + dvb_frontend_detach(adap->fe_adap[i].fe);
> + }
> + }
> + adap->num_frontends_initialized = 0;
> + }
> +
> + dvb_usb_device_exit(intf);
> +}
> +
> static struct usb_device_id gp8psk_usb_table [] = {
> { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_8PSK_REV_1_COLD) },
> { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_8PSK_REV_1_WARM) },
> @@ -338,7 +364,7 @@ static struct dvb_usb_device_properties gp8psk_properties = {
> static struct usb_driver gp8psk_usb_driver = {
> .name = "dvb_usb_gp8psk",
> .probe = gp8psk_usb_probe,
> - .disconnect = dvb_usb_device_exit,
> + .disconnect = gp8psk_usb_disconnect,
> .id_table = gp8psk_usb_table,
> };
>
^ permalink raw reply
* Re: [B.A.T.M.A.N.] i have a question ? How many relay nodes can be supported at NetworkCoding ( mtu 1546 ) .
From: johnzeng @ 2016-11-09 5:59 UTC (permalink / raw)
To: Linus Lüssing
Cc: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <20161109052815.GG3391@otheros>
Hello Dear Linus:
Ok , i see , i will test it in according to
your advisement .
Thanks , have a good day with you
Tiger
于 2016年11月09日 13:28, Linus Lüssing 写道:
> On Wed, Nov 09, 2016 at 04:50:45AM +0100, johnzeng via B.A.T.M.A.N wrote:
>> Date: Wed, 09 Nov 2016 11:50:30 +0800
>> From: johnzeng <johnzeng2013@yahoo.com>
>> To: Simon Wunderlich <sw@simonwunderlich.de>
>> CC: b.a.t.m.a.n@lists.open-mesh.org, Sven Eckelmann <sven@narfation.org>,
>> Martin Hundebøll <martin@hundeboll.net>
>> Subject: Re: [B.A.T.M.A.N.] i have a question ? How many relay nodes can be
>> supported at NetworkCoding ( mtu 1546 ) .
>>
>> I can understand network coding , it will be
>> same as proxy or Intermediator at Layer 2 ,
> Maybe there is a complete misunderstanding what "network coding"
> is?
>
> Maybe an easier expression would be "packet mixing" or "magic packet
> mangling" [1].
>
> Any code that does something with networking is usually *not*
> "network coding" (at least in this context here).
>
> Have a look at the links Sven has provided earlier.
>
>>
>> Your meaning : Batman-adv can build Similar
>> mechanism ( Intermediator ) via intermediator , it wil be relay based real
>> application packet ( not relay based Broadcast packet)
> Just try it :-). Compile batman-adv *without network coding* with
> your A-B-C scenario and see how it magically works, too :-).
>
> Regards, Linus
>
>
> [1]: Please no expert hit me :D. I know, ultimately, network coding would
> replace packet based networks, if I remember Frank's talk
> in Leipzig correctly
>
> https://www.youtube.com/watch?v=yluj7e_rfVE
^ permalink raw reply
* Re: rdma-core example spec file is broken
From: Leon Romanovsky @ 2016-11-09 5:59 UTC (permalink / raw)
To: Alaa Hleihel
Cc: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
yishaih-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <f807db01-c4c7-0f64-fe6b-476d02b686b3-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On Tue, Nov 08, 2016 at 04:47:21PM +0200, Alaa Hleihel wrote:
> I tested this patch.
> It resolves the issue.
Thanks, applied.
>
> Thanks,
> Alaa
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 01/16] Git.pm: add subroutines for commenting lines
From: Junio C Hamano @ 2016-11-09 1:06 UTC (permalink / raw)
To: Vasco Almeida
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar
In-Reply-To: <20161108120823.11204-2-vascomalmeida@sapo.pt>
Vasco Almeida <vascomalmeida@sapo.pt> writes:
> Add subroutines prefix_lines and comment_lines.
>
> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
> ---
> perl/Git.pm | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/perl/Git.pm b/perl/Git.pm
> index b2732822a..17be59fb7 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -1438,6 +1438,29 @@ sub END {
>
> } # %TEMP_* Lexical Context
>
> +=item prefix_lines ( PREFIX, STRING )
> +
> +Prefixes lines in C<STRING> with C<PREFIX>.
> +
> +=cut
> +
> +sub prefix_lines {
> + my ($prefix, $string) = @_;
> + $string =~ s/^/$prefix/mg;
> + return $string;
> +}
> +
> +=item comment_lines ( STRING )
> +
> +Comments lines following core.commentchar configuration.
> +
> +=cut
> +
> +sub comment_lines {
> + my $comment_line_char = config("core.commentchar") || '#';
> + return prefix_lines("$comment_line_char ", @_);
> +}
> +
This makes it appear as if comment_lines can take arbitrary number
of strings as its arguments (because the outer caller just passes @_
thru), but in fact because prefix_lines ignores anything other than
$_[0] and $_[1], only the first parameter given to comment_lineS sub
is inspected for lines in it and the prefix-char prefixed at the
beginning of each of them.
Which is not a great interface, as it is quite misleading.
Perhaps
prefix_lines("#", join("\n", @_));
or something like that may make it less confusing.
^ permalink raw reply
* Re: git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n
From: Junio C Hamano @ 2016-11-08 21:31 UTC (permalink / raw)
To: Stefan Beller; +Cc: Anthony Sottile, git@vger.kernel.org
In-Reply-To: <CAGZ79kbyM0ssz3JgeNHsUpvHnBsCbhm-tHvHRp3+6O1QvmkYpw@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> On Mon, Nov 7, 2016 at 10:30 AM, Anthony Sottile <asottile@umich.edu> wrote:
>> This has worked great up until now (and is very convenient for trying things
>> out without blowing away the system installation). What changed?
>>
>
> (Just guessing myself:)
>
> $ git log --grep git-sh-i18n v2.10.0..v2.11.0-rc0
> ...
> commit 1073094f30a8dd5ae49f2146f587085c4fe86410
> Author: Anders Kaseorg <andersk@mit.edu>
> Date: Sat Oct 29 22:10:02 2016 -0400
>
> git-sh-setup: be explicit where to dot-source git-sh-i18n from.
>
> d323c6b641 ("i18n: git-sh-setup.sh: mark strings for translation",
> 2016-06-17) started to dot-source git-sh-i18n shell script library,
> assuming that $PATH is already adjusted for our scripts, namely,
> $GIT_EXEC_PATH is at the beginning of $PATH.
> ...
Before that one since v2.10.0, there ie d323c6b641 that starts to
include git-sh-i18n from git-sh-setup in the first place. If you are
testing or using a newly-out-of-oven uninstalled Git, you would need
to do these to be correctly using it:
* Many subcommand executables and helpers are not installed on any
directory on your $PATH, but are installed in GIT_EXEC_PATH.
Find out where it is by asking the newly-out-of-oven Git "git
--exec-path" without setting GIT_EXEC_PATH environment variable.
That is where your newly built one wants to find things.
* Because you are trying to use the newly-out-of-oven Git without
installing, you do not want to install into the real
GIT_EXEC_PATH location yet. Pick a new empty directory and
arrange the files that would be installed by our Makefile into
"git --exec-path" if you did "make install" to be in this new
location. The set of files include git-sh-setup and git-sh-i18n.
* Set and export GIT_EXEC_PATH to point at this new empty directory
you just populated.
That incidentally is how we make our "make test" work.
If you only set $PATH to the top of git build directory, without
doing the above arrangement with GIT_EXEC_PATH, things may have
appeared to work due to multitude of accidents. Builtin commands
would worked fine because it is just a single "git" binary after
all, i.e. "git log" would not have consulted a "git-log" binary on
anywhere in your filesystem. Other commands may have been run from
the already installed version on the system. The latter is
particularly problematic, because it means that one thought that one
is testing the newly built on before installing to make sure that
the new one works OK, but is actually testing the already installed
one.
^ permalink raw reply
* Re: [PATCH v4 1/2] lib-proto-disable: variable name fix
From: Junio C Hamano @ 2016-11-08 20:52 UTC (permalink / raw)
To: Jacob Keller
Cc: Jeff King, Brandon Williams, Git mailing list, Stefan Beller,
bburky, Jonathan Nieder
In-Reply-To: <CA+P7+xohFeWb1hsOg1_T1kWenc=AKrt1TNcx=TrVYQ+w3+c63Q@mail.gmail.com>
Jacob Keller <jacob.keller@gmail.com> writes:
> On Mon, Nov 7, 2016 at 12:48 PM, Jeff King <peff@peff.net> wrote:
>> It's possible that I'm overly picky about my commit messages, but that
>> does not stop me from trying to train an army of picky-commit-message
>> clones. :)
>>
>> -Peff
>
> You're not the only one ;)
Somebody seems to have trained y'all very well ;-)
^ permalink raw reply
* Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred
From: Viresh Kumar @ 2016-11-09 5:55 UTC (permalink / raw)
To: Stratos Karafotis
Cc: linux-pm@vger.kernel.org, Linux Kernel Mailing List,
Rafael J. Wysocki
In-Reply-To: <5ea3831e-7743-d39f-1f02-96c915cc757e@semaphore.gr>
On 08-11-16, 21:25, Stratos Karafotis wrote:
> But this is the supposed behaviour of conservative governor. We want
> the CPU to increase the frequency in steps. The patch just resets
> the frequency to a lower frequency in case of idle.
>
> For argument's sake, let's assume that the governor timer is never
> deferred and runs every sampling period even on completely idle CPU.
There are no timers now :)
> And let's assume, for example, a burst load that runs every 100ms
> for 20ms. The default sampling rate is also 20ms.
> What would conservative do in case of that burst load? It would
> increase the frequency by one freq step after 20ms and then it would
> decrease the frequency 4 times by one frequency step. Most probably
> on the next burst load, the CPU will run on min frequency.
>
> I agree that maybe this is not ideal for performance but maybe this is
> how we want conservative governor to work (lazily increase and decrease
> frequency).
Idle periods are already accounted for while calculating system load by legacy
governors.
And the more and more I think about this, I am inclined towards your patch.
Maybe in a bit different form and commit log.
If we see how the governors were written initially, there were no deferred
timers. And so even if CPUs were idle, we will wake up to adjust the step.
Even if we want to make the behavior similar to that, then also we should
account of missed sampling periods both while decreasing or increasing
frequencies.
@Rafael: What do you think ?
--
viresh
^ permalink raw reply
* Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
From: Junio C Hamano @ 2016-11-09 5:55 UTC (permalink / raw)
To: Ian Jackson; +Cc: Jeff King, Jacob Keller, Git mailing list, Paul Mackerras
In-Reply-To: <22562.32428.287354.214659@chiark.greenend.org.uk>
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> I think the two things I found weird were:
>>
>> - it's in the "log" section, which makes me think it's an option for
>> git-log. But it's not. I'm not sure what the _right_ section is, but
>> hopefully it would make it clear that this is command-agnostic.
>>
>> Something like "gui.abbrevTags" might be OK (and as you note, has
>> precedence). But of course it's possible that a command like "tig"
>> could learn to support it. I'm not sure if that counts as a GUI or
>> not. :)
>
> I don't really have an opinion about the name. gui.abbrevTags would
> be a possibility. (It's a bit odd that implicitly, the default would
> be `*'.)
I have trouble with both "log" and "abbrev" in the name. Perhaps I
am biased by our recent discussion on a feature in the core that we
use the word "abbrev" to describe, but I fear that most Git users,
when told the word, would imagine the act of shortening 40-hex full
object name down to shorter but still unique prefix, not the "this
refname is too long, so let's show only the first few letters in GUI
label".
And I do not think we would want "log" or any core side Porcelain
command to have too many "information losing" options like this
"truncate refnames down to a point where it is no longer unique and
meaningful". GUI tools can get away with doing sos because they can
arrange these truncated labels to react to end-user input (e.g. the
truncated Tag in the history display of gitk could be made to react
to mouse-over and pop-up to show a full name, for example), but the
output from the core side is pretty much fixed once it is emitted.
So my first preference would be to teach gitk such a "please
clarify" UI-reaction, if it does not know how to do so yet. There
is no need for a configuration variable anywhere with this approach.
If you do want to add a configuration to show fuller name in the
tag, which would make it unnecessary for the user to do "please
clarify, as I am hovering over what I want to get details of"
action, that may also be a good way to go. But I think the right
place to do so would be Edit -> Preferences menu in Gitk, and the
settings will be stored in ~/.gitk or ~/.config/git/gitk or whatever
gitk-specific place.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.