* cuboot-pq2.c:undefined reference to `fsl_get_immr'
From: Fengguang Wu @ 2014-01-10 8:38 UTC (permalink / raw)
To: Tony Breeds; +Cc: Linux PPC dev, kbuild-all
In-Reply-To: <52cfaccd.zB+xVDXQN1I7DXJ2%fengguang.wu@intel.com>
Hi Tony,
FYI, kernel build failed on
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 7d1c153ab373a5c07feb97eaf4e4bcad5bfc262e
commit: b81f18e55e9f4ea81759bcb00fea295de679bbe8 powerpc/boot: Only build board support files when required.
date: 1 year, 6 months ago
config: make ARCH=powerpc storcenter_defconfig
All error/warnings:
arch/powerpc/boot/cuboot-pq2.o: In function `pq2_platform_fixups':
>> cuboot-pq2.c:(.text+0x320): undefined reference to `fsl_get_immr'
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
^ permalink raw reply
* [PATCH] PPC: KVM: fix VCPU run for HV KVM
From: Alexey Kardashevskiy @ 2014-01-10 7:21 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Michael S. Tsirkin, Alexey Kardashevskiy, linux-kernel,
kvm-ppc, Alexander Graf, Paul Mackerras
When write to MMIO happens and there is an ioeventfd for that and
is handled successfully, ioeventfd_write() returns 0 (success) and
kvmppc_handle_store() returns EMULATE_DONE. Then kvmppc_emulate_mmio()
converts EMULATE_DONE to RESUME_GUEST_NV and this broke from the loop.
This adds handling of RESUME_GUEST_NV in kvmppc_vcpu_run_hv().
Cc: Michael S. Tsirkin <mst@redhat.com>
Suggested-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
This definitely needs a better commit message. Please, help.
ps. it seems like ioeventfd never worked on ppc64. hm.
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 072287f..24f363f 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1569,7 +1569,7 @@ static int kvmppc_vcpu_run_hv(struct kvm_run *run, struct kvm_vcpu *vcpu)
vcpu->arch.fault_dar, vcpu->arch.fault_dsisr);
srcu_read_unlock(&vcpu->kvm->srcu, srcu_idx);
}
- } while (r == RESUME_GUEST);
+ } while ((r == RESUME_GUEST_NV) || (r == RESUME_GUEST));
out:
vcpu->arch.state = KVMPPC_VCPU_NOTREADY;
--
1.8.4.rc4
^ permalink raw reply related
* warning: (PPC_PSERIES && ..) selects HOTPLUG_CPU which has unmet direct dependencies (SMP && ..))
From: Fengguang Wu @ 2014-01-10 4:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Greg Kroah-Hartman, LKML, kbuild-all
In-Reply-To: <52cebbdf.VOHKy5gPVEgnVPcm%fengguang.wu@intel.com>
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 7d1c153ab373a5c07feb97eaf4e4bcad5bfc262e
commit: bb07b00be77fb33274cb44a03bdbf2471e556189 Merge 3.10-rc6 into driver-core-next
date: 7 months ago
config: make ARCH=powerpc mpc86xx_defconfig
All warnings:
warning: (PPC_PSERIES && PM_SLEEP_SMP) selects HOTPLUG_CPU which has unmet direct dependencies (SMP && (PPC_PSERIES || PPC_PMAC || PPC_POWERNV || PPC_85xx && !PPC_E500MC))
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
^ permalink raw reply
* [PATCH v8] clk: corenet: Adds the clock binding
From: Tang Yuantian @ 2014-01-10 2:29 UTC (permalink / raw)
To: b07421; +Cc: mark.rutland, devicetree, Tang Yuantian, linuxppc-dev
From: Tang Yuantian <yuantian.tang@freescale.com>
Adds the clock bindings for Freescale PowerPC CoreNet platforms
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
v8:
- added clock-frequency property description
- fixed whitespace and tab mixing issue
v7:
- refined some properties' definitions
v6:
- splited the previous patch into 2 parts, one is for binding(this one),
the other is for DTS modification(will submit once this gets accepted)
- fixed typo
- refined #clock-cells and clock-output-names properties
- removed fixed-clock compatible string
v5:
- refine the binding document
- update the compatible string
v4:
- add binding document
- update compatible string
- update the reg property
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
.../devicetree/bindings/clock/corenet-clock.txt | 133 +++++++++++++++++++++
1 file changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 0000000..abb0493
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,133 @@
+* Clock Block on Freescale CoreNet Platforms
+
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+which can then be passed to a variety of internal logic, including
+cores and peripheral IP blocks.
+Please refer to the Reference Manual for details.
+
+1. Clock Block Binding
+
+Required properties:
+- compatible: Should contain a specific clock block compatible string
+ and a single chassis clock compatible string.
+ Clock block strings include, but not limited to, one of the:
+ * "fsl,p2041-clockgen"
+ * "fsl,p3041-clockgen"
+ * "fsl,p4080-clockgen"
+ * "fsl,p5020-clockgen"
+ * "fsl,p5040-clockgen"
+ * "fsl,t4240-clockgen"
+ * "fsl,b4420-clockgen"
+ * "fsl,b4860-clockgen"
+ Chassis clock strings include:
+ * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
+ * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
+- reg: Offset and length of the clock register set
+
+Recommended properties:
+- clock-frequency: Input system clock frequency. Must be present
+ if the device has sub-nodes.
+- ranges: Allows valid translation between child's address space and
+ parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+ physical base addresses. Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
+
+2. Clock Provider/Consumer Binding
+
+Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Should include one of the following:
+ * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
+ * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
+ * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
+ * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
+ * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
+ It takes parent's clock as its clock.
+ * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
+ It takes parent's clock as its clock.
+- #clock-cells: From common clock binding. The number of cells in a
+ clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
+ clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
+ For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
+ clock-specifier cell may take the following values:
+ * 0 - equal to the PLL frequency
+ * 1 - equal to the PLL frequency divided by 2
+ * 2 - equal to the PLL frequency divided by 4
+
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
+- clock-output-names: From common clock binding, indicates the names of
+ output clocks
+- reg: Should be the offset and length of clock block base address.
+ The length should be 4.
+
+Example for clock block and clock provider:
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
+ ranges = <0x0 0xe1000 0x1000>;
+ clock-frequency = <0>;
+ reg = <0xe1000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysclk: sysclk {
+ #clock-cells = <0>;
+ compatible = "fsl,qoriq-sysclk-1.0";
+ clock-output-names = "sysclk";
+ }
+
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800 0x4>;
+ compatible = "fsl,qoriq-core-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820 0x4>;
+ compatible = "fsl,qoriq-core-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0 0x4>;
+ compatible = "fsl,qoriq-core-mux-1.0";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux0";
+ };
+
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20 0x4>;
+ compatible = "fsl,qoriq-core-mux-1.0";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux1";
+ };
+ };
+ }
+
+Example for clock consumer:
+
+/ {
+ cpu0: PowerPC,e5500@0 {
+ ...
+ clocks = <&mux0>;
+ ...
+ };
+ }
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver
From: Nicolin Chen @ 2014-01-10 2:35 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland, devicetree, alsa-devel, shawn.guo, pawel.moll,
ijc+devicetree, tiwai, linux-kernel, linux-doc, timur, lgirdwood,
robh+dt, rob, galak, grant.likely, perex, linuxppc-dev
In-Reply-To: <20140110023252.GA16467@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]
Resent this because of losing attached file.
On Fri, Jan 10, 2014 at 10:32:52AM +0800, Nicolin Chen wrote:
> On Thu, Jan 09, 2014 at 06:44:53PM +0000, Mark Brown wrote:
> > On Thu, Jan 09, 2014 at 06:57:58PM +0800, Nicolin Chen wrote:
> >
> > > +/**
> > > + * This function configures the ratio between MCLK (HCK) and BCLK (SCK)
> > > + * (For DAI Master Mode only)
> > > + *
> > > + * Note: Machine driver should calculate the ratio to call this function.
> > > + * Only effective after calling set_dai_sysclk() to set HCK direction.
> > > + */
> > > +static int fsl_esai_set_bclk_ratio(struct snd_soc_dai *dai, unsigned int ratio)
> >
> > Why does the machine driver have to do this by hand, being able to
> > override is fine but having sensible defaults is easier? Or does it
> > actually do that and the comment just needs updating?
>
> The divider part of ESAI is pretty complicated due to caring about three
> configure bits - ETO, ETI, HCKD. (I've attached a diagram to this mail.)
> So setting sysclk() alone is not enough to take care all the configurations.
> That's why I designed these two interfaces at the first place. And it should
> be hard to find a default situation.
>
> But there is one approach to omit this calling for machine driver is to do
> the set_bclk_ratio() at this CPU DAI driver. And this might be a good idea
> because we can then separate the settings between PLAYBACK and CAPTURE, even
> though we might then need to check the Master or Slave state to apply the
> settings accordingly.
>
> I'll try this idea in v3 if you feel it's plausible.
>
> > > + ret = devm_snd_soc_register_component(&pdev->dev, &fsl_esai_component,
> > > + &fsl_esai_dai, 1);
> > > + if (ret) {
> > > + dev_err(&pdev->dev, "failed to register DAI: %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = imx_pcm_dma_init(pdev);
> > > + if (ret)
> > > + dev_err(&pdev->dev, "failed to init imx pcm dma: %d\n", ret);
> > > +
> > > + /* Reset ESAI unit */
> > > + regmap_write(esai_priv->regmap, REG_ESAI_ECR, ESAI_ECR_ERST);
> > > +
> > > + /*
> > > + * We need to enable ESAI so as to access some of its registers.
> > > + * Otherwise, we would fail to dump regmap from user space.
> > > + */
> > > + regmap_write(esai_priv->regmap, REG_ESAI_ECR, ESAI_ECR_ESAIEN);
> >
> > I would expect to see the hardware initialisation before we start
> > registering with the core otherwise the core might start trying to run
> > prior to the hardware being initialised.
>
> Will switch this initial code in v3 as your suggestion.
>
> Thank you,
> Nicolin Chen
[-- Attachment #2: esai_div.jpg --]
[-- Type: image/jpeg, Size: 61359 bytes --]
^ permalink raw reply
* RE: [v6,4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Dongsheng.Wang @ 2014-01-10 2:44 UTC (permalink / raw)
To: Scott Wood; +Cc: Bharat.Bhushan@freescale.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140109235134.GA24262@home.buserror.net>
> /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:326:19: er=
ror:
> 'PWRMGTCR0_AV_IDLE_CNT' undeclared (first use in this function)
> /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:329:36: er=
ror:
> 'PWRMGTCR0_AV_IDLE_CNT_SHIFT' undeclared (first use in this function)
> make[2]: *** [arch/powerpc/kernel/sysfs.o] Error 1
> make[1]: *** [arch/powerpc/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [sub-make] Error 2
>=20
> I'll fix when applying with this:
>=20
:), Thanks.=20
-Dongsheng
^ permalink raw reply
* RE: 答复: [v7] clk: corenet: Adds the clock binding
From: Yuantian Tang @ 2014-01-10 2:38 UTC (permalink / raw)
To: Scott Wood
Cc: Mark Rutland, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1389302368.14390.33.camel@snotra.buserror.net>
VGhhbmtzIGZvciB5b3VyIHJldmlldy4gSSB3aWxsIHNlbmQgbmV4dCB2ZXJzaW9uIG9mIHBhdGNo
Lg0KDQpUaGFua3MsDQpZdWFudGlhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4gU2VudDogMjAxNOW5tDHmnIgxMOaXpSDmmJ/m
nJ/kupQgNToxOQ0KPiBUbzogVGFuZyBZdWFudGlhbi1CMjk5ODMNCj4gQ2M6IE1hcmsgUnV0bGFu
ZDsgZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7
DQo+IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiDnrZTlpI06
IFt2N10gY2xrOiBjb3JlbmV0OiBBZGRzIHRoZSBjbG9jayBiaW5kaW5nDQo+IA0KPiBPbiBXZWQs
IDIwMTQtMDEtMDggYXQgMjA6NTcgLTA2MDAsIFRhbmcgWXVhbnRpYW4tQjI5OTgzIHdyb3RlOg0K
PiA+IFRoYW5rcyBmb3IgeW91IHJldmlldy4NCj4gPiBTZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0K
PiA+DQo+ID4gVGhhbmtzLA0KPiA+IFl1YW50aWFuDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDog
MjAxNOW5tDHmnIg55pelIOaYn+acn+WbmyAyOjQ0DQo+ID4gPiBUbzogTWFyayBSdXRsYW5kDQo+
ID4gPiBDYzogVGFuZyBZdWFudGlhbi1CMjk5ODM7IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7
DQo+ID4gPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiDnrZTlpI06IFt2N10gY2xrOiBjb3JlbmV0OiBB
ZGRzIHRoZSBjbG9jayBiaW5kaW5nDQo+ID4gPg0KPiA+ID4gT24gV2VkLCAyMDE0LTAxLTA4IGF0
IDA5OjMwICswMDAwLCBNYXJrIFJ1dGxhbmQgd3JvdGU6DQo+ID4gPiA+IE9uIFdlZCwgSmFuIDA4
LCAyMDE0IGF0IDA4OjUzOjU2QU0gKzAwMDAsIFl1YW50aWFuIFRhbmcgd3JvdGU6DQo+ID4gPiA+
ID4NCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4gPiA+ID4g5Y+R5Lu25Lq6OiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+IOWPkemAgeaX
tumXtDogMjAxNOW5tDHmnIg45pelIDg6MjENCj4gPiA+ID4gPiDmlLbku7bkuro6IFRhbmcgWXVh
bnRpYW4tQjI5OTgzDQo+ID4gPiA+ID4g5oqE6YCBOiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3Jn
OyBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsNCj4gPiA+ID4gPiBkZXZpY2V0cmVlQHZnZXIua2VybmVs
Lm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiA+ID4gPiDkuLvpopg6IFJl
OiBbdjddIGNsazogY29yZW5ldDogQWRkcyB0aGUgY2xvY2sgYmluZGluZw0KPiA+ID4gPiA+DQo+
ID4gPiA+ID4gT24gV2VkLCBOb3YgMjAsIDIwMTMgYXQgMDU6MDQ6NDlQTSArMDgwMCwgdGFuZyB5
dWFudGlhbiB3cm90ZToNCj4gPiA+ID4gPiA+ICtSZWNvbW1lbmRlZCBwcm9wZXJ0aWVzOg0KPiA+
ID4gPiA+ID4gKy0gcmFuZ2VzOiBBbGxvd3MgdmFsaWQgdHJhbnNsYXRpb24gYmV0d2VlbiBjaGls
ZCdzIGFkZHJlc3MNCj4gPiA+ID4gPiA+ICtzcGFjZQ0KPiA+ID4gYW5kDQo+ID4gPiA+ID4gPiAr
ICAgICBwYXJlbnQncy4gTXVzdCBiZSBwcmVzZW50IGlmIHRoZSBkZXZpY2UgaGFzIHN1Yi1ub2Rl
cy4NCj4gPiA+ID4gPiA+ICstICNhZGRyZXNzLWNlbGxzOiBTcGVjaWZpZXMgdGhlIG51bWJlciBv
ZiBjZWxscyB1c2VkIHRvDQo+IHJlcHJlc2VudA0KPiA+ID4gPiA+ID4gKyAgICAgcGh5c2ljYWwg
YmFzZSBhZGRyZXNzZXMuICBNdXN0IGJlIHByZXNlbnQgaWYgdGhlIGRldmljZQ0KPiBoYXMNCj4g
PiA+ID4gPiA+ICsgICAgIHN1Yi1ub2RlcyBhbmQgc2V0IHRvIDEgaWYgcHJlc2VudA0KPiA+ID4g
PiA+ID4gKy0gI3NpemUtY2VsbHM6IFNwZWNpZmllcyB0aGUgbnVtYmVyIG9mIGNlbGxzIHVzZWQg
dG8gcmVwcmVzZW50DQo+ID4gPiA+ID4gPiArICAgICB0aGUgc2l6ZSBvZiBhbiBhZGRyZXNzLiBN
dXN0IGJlIHByZXNlbnQgaWYgdGhlIGRldmljZSBoYXMNCj4gPiA+ID4gPiA+ICsgICAgIHN1Yi1u
b2RlcyBhbmQgc2V0IHRvIDEgaWYgcHJlc2VudA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2h5IGFy
ZSB3ZSBzcGVjaWZ5aW5nICNhZGRyZXNzLWNlbGxzLyNzaXplLWNlbGxzIGhlcmU/DQo+ID4gPiA+
ID4NCj4gPiA+ID4gPiBBOiBpdCBoYXMgc3ViLW5vZGVzIHdoaWNoIGhhdmUgUkVHIHByb3BlcnR5
LCBkb24ndCB3ZSBuZWVkIHRvDQo+ID4gPiA+ID4gc3BlY2lmeSAjYWRkcmVzcy1jZWxscy8jc2l6
ZS1jZWxscz8NCj4gPiA+ID4NCj4gPiA+ID4gSWYgYSBub2RlIGhhcyBhIHJlZyBlbnRyeSwgaXRz
IHBhcmVudCBzaG91bGQgaGF2ZSAjc2l6ZS1jZWxscyBhbmQNCj4gPiA+ID4gI2FkZHJlc3MtY2Vs
bHMgdG8gYWxsb3cgaXQgdG8gYmUgcGFyc2VkIHByb3Blcmx5Lg0KPiA+ID4NCj4gPiA+IFllcywg
YnV0IHdoeSBkbyB3ZSBuZWVkIHRvIHNwZWNpZnkgaW4gdGhpcyBiaW5kaW5nIGhvdyBtYW55IGNl
bGxzDQo+ID4gPiB0aGVyZSB3aWxsIGJlLCBlc3BlY2lhbGx5IHNpbmNlIHRoaXMgYmluZGluZyBv
bmx5IGFkZHJlc3NlcyB0aGUNCj4gPiA+IGNsb2NrIHByb3ZpZGVyIGFzcGVjdCBvZiB0aGUgY2xv
Y2tnZW4gbm9kZXMgKGUuZy4gaXQgZG9lc24ndA0KPiA+ID4gZGVzY3JpYmUgdGhlIHJlZyk/ICBP
ciByYXRoZXIsIGl0J3MgcGFydGlhbGx5IGRlc2NyaWJpbmcgdGhlDQo+ID4gPiBub24tY2xvY2sg
YXNwZWN0LCBhbmQgZG9lc24ndCBhZGRyZXNzIHRoZSBjbG9jayBhc3BlY3QgYXQgYWxsIEFGQUlD
VC4NCj4gPiA+DQo+ID4gRmlyc3Qgb2YgYWxsLCB0aGV5IGFyZSBub3QgIlJlcXVpcmVkIHByb3Bl
cnRpZXMiLCB0aGV5IGFyZSBvcHRpb25hbC4NCj4gPiBJZiBwcmVzZW50LCB3ZSBzaG91bGQgZ2l2
ZSB0aGVtIGEgdmFsdWUgb2YgMS4NCj4gDQo+IFdoeSBkb2VzIGl0IG1hdHRlciwgc28gbG9uZyBh
cyB0aGUgdmFsdWVzIHRyYW5zbGF0ZSBwcm9wZXJseT8gIEl0J3Mgbm90DQo+IGFzIGlmIHlvdSdy
ZSBkZWZpbmluZyBhIHNwZWNpYWwgcmVnIGZvcm1hdC4gIEl0J3Mgbm90IHRoYXQgYmlnIG9mIGEg
ZGVhbCwNCj4gYnV0IGl0IHNlZW1zIHVubmVjZXNzYXJ5Lg0KPiANCj4gPiBUaGVuLCB5ZXMsIHRo
aXMgYmluZGluZyBkZXNjcmliZXMgY2xvY2tnZW4gbm9kZSB3aGljaCBpcyAiQ0xPQ0sgQkxPQ0si
Lg0KPiANCj4gU29ycnksIEkgbWlzc2VkIHdoZXJlICJyZWciIHdhcyBkb2N1bWVudGVkIGR1ZSB0
byB0aGUNCj4gcmVxdWlyZWQvcmVjb21tZW5kZWQgc3BsaXQuDQo+IA0KPiA+ID4gV2hlcmUgZG9l
cyB0aGUgYWN0dWFsIGlucHV0IGNsb2NrIGZyZXF1ZW5jeSBnbz8gIFUtQm9vdCBwdXRzIGl0IGlu
DQo+ID4gPiB0aGUgY2xvY2tnZW4gbm9kZSBpdHNlbGYgYXMgY2xvY2stZnJlcXVlbmN5LCBidXQg
dGhhdCBpc24ndA0KPiA+ID4gZGVzY3JpYmVkIGluIHRoZSBiaW5kaW5nLiAgSG93IGRvZXMgdGhh
dCByZWxhdGUgdG8gdGhlIHN5c2NsayBub2RlPw0KPiA+ID4gSWYgImZzbCxxb3JpcS1zeXNjbGst
IDEuMCIgaXMgc3VwcG9zZWQgdG8gaW5kaWNhdGUgdGhhdA0KPiA+ID4gY2xvY2stZnJlcXVlbmN5
IGNhbiBiZSBmb3VuZCBpbiB0aGUgcGFyZW50IG5vZGUsIHRoYXQgaXNuJ3QNCj4gPiA+IHNwZWNp
ZmllZCBieSB0aGUgYmluZGluZywgbm9yIGlzIGNsb2NrLWZyZXF1ZW5jeSBzaG93biBpbiB0aGUg
ZXhhbXBsZS4NCj4gPiA+DQo+ID4gY2xvY2stZnJlcXVlbmN5IGlzIGEgd2lyZWQgcHJvcGVydHku
DQo+IA0KPiBEbyB5b3UgbWVhbiAid2VpcmQiPw0KPiANCj4gPiBJdCBpcyBpbiBjbG9ja2dlbiBu
b2RlIHJpZ2h0IG5vdy4NCj4gPiBCdXQgaXQgc2hvdWxkIGJlIHBsYWNlZCBzb21ld2hlcmUgaW4g
Y2xvY2sgbm9kZXMuDQo+IA0KPiBJZiB3ZSB3ZXJlIGRvaW5nIHRoaXMgZnJvbSBzY3JhdGNoLCB5
ZXMsIGJ1dCB0aGVyZSdzIGV4aXN0aW5nIFUtQm9vdCBjb2RlDQo+IHRoYXQgd2Ugd2FudCB0byBi
ZSBjb21wYXRpYmxlIHdpdGguDQo+IA0KPiA+IElmIEkgZGVzY3JpYmUgaGVyZSwgSSB3b3VsZCBi
ZSBhc2tlZCB3aHkgaXQgaXMgcmVsYXRlZCB0byBjbG9ja2dlbiBub2RlPw0KPiANCj4gVGhhdCdz
IG5vdCBhIGdvb2QgcmVhc29uIHRvIGxlYXZlIGl0IHVuZG9jdW1lbnRlZC4NCj4gDQo+ID4gPiBX
aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gImZzbCxxb3JpcS1zeXNjbGstMS4wIiBhbmQN
Cj4gPiA+ICJmc2wscW9yaXEtIHN5c2Nsay0yLjAiPyAgSG93IGRvZXMgdGhlIGNvbmNlcHQgb2Yg
YSBmaXhlZCBpbnB1dCBjbG9jaw0KPiBjaGFuZ2U/DQo+ID4gPg0KPiA+IFRlY2huaWNhbGx5LCB0
aGVyZSBpcyBubyBkaWZmZXJlbmNlIGJldHdlZW4gKnN5c2Nsay0xLjAgYW5kICotMi4wLA0KPiA+
IGp1c3QgbGlrZQ0KPiA+IENsb2NrZ2VuLTIuMCBhbmQgMS4wLiBOYW1pbmcgbGlrZSB0aGlzIGp1
c3QgdG8gaW5kaWNhdGUgdGhleSBiZWxvbmcgdG8NCj4gPiBjaGFzc2lzIDIuMCBhbmQgMS4wIHJl
c3BlY3RpdmVseS4NCj4gDQo+IEkgZ3Vlc3MgaXQncyBPSyBpZiBpdCBlbmNvdXJhZ2VzIHBlb3Bs
ZSB0byBjb25zaWRlciBzd2l0Y2hpbmcgdG8gdGhlDQo+IHN0YW5kYXJkIGZpeGVkLWNsb2NrIGZv
ciBmdXR1cmUgY2hhc3Npcy4NCj4gDQo+IFNvIHRoZSBvbmx5IHRoaW5nIHRoYXQgcmVhbGx5IG5l
ZWRzIHRvIGJlIGZpeGVkIGlzIHRoZSBtaXNzaW5nIGNsb2NrLQ0KPiBmcmVxdWVuY3kgZG9jdW1l
bnRhdGlvbi4NCj4gDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* Re: [v6,4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2014-01-09 23:51 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: Bharat.Bhushan, linuxppc-dev
In-Reply-To: <1387268222-9703-4-git-send-email-dongsheng.wang@freescale.com>
On Tue, Dec 17, 2013 at 04:17:02PM +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Add a sys interface to enable/diable pw20 state or altivec idle, and
> control the wait entry time.
>
> Enable/Disable interface:
> 0, disable. 1, enable.
> /sys/devices/system/cpu/cpuX/pw20_state
> /sys/devices/system/cpu/cpuX/altivec_idle
>
> Set wait time interface:(Nanosecond)
> /sys/devices/system/cpu/cpuX/pw20_wait_time
> /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> Example: Base on TBfreq is 41MHZ.
> 1~48(ns): TB[63]
> 49~97(ns): TB[62]
> 98~195(ns): TB[61]
> 196~390(ns): TB[60]
> 391~780(ns): TB[59]
> 781~1560(ns): TB[58]
> ...
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
This causes ppc6xx_defconfig to fail to build:
CC arch/powerpc/kernel/sysfs.o
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'show_pw20_state':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:125:11: error: 'PWRMGTCR0_PW20_WAIT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:125:11: note: each undeclared identifier is reported only once for each function it appears in
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'do_store_pw20_state':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:138:17: error: 'PWRMGTCR0_PW20_WAIT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'show_pw20_wait_time':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:174:20: error: 'PWRMGTCR0_PW20_ENT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:175:6: error: 'PWRMGTCR0_PW20_ENT_SHIFT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'set_pw20_wait_entry_bit':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:204:16: error: 'PWRMGTCR0_PW20_ENT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:207:33: error: 'PWRMGTCR0_PW20_ENT_SHIFT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'show_altivec_idle':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:247:11: error: 'PWRMGTCR0_AV_IDLE_PD_EN' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'do_store_altivec_idle':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:260:19: error: 'PWRMGTCR0_AV_IDLE_PD_EN' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'show_altivec_idle_wait_time':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:296:20: error: 'PWRMGTCR0_AV_IDLE_CNT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:297:6: error: 'PWRMGTCR0_AV_IDLE_CNT_SHIFT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c: In function 'set_altivec_idle_wait_entry_bit':
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:326:19: error: 'PWRMGTCR0_AV_IDLE_CNT' undeclared (first use in this function)
/home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/sysfs.c:329:36: error: 'PWRMGTCR0_AV_IDLE_CNT_SHIFT' undeclared (first use in this function)
make[2]: *** [arch/powerpc/kernel/sysfs.o] Error 1
make[1]: *** [arch/powerpc/kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [sub-make] Error 2
I'll fix when applying with this:
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 9af9e37..d4a43e6 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -86,7 +86,7 @@ __setup("smt-snooze-delay=", setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
-#ifdef CONFIG_FSL_SOC
+#ifdef CONFIG_PPC_FSL_BOOK3E
#define MAX_BIT 63
static u64 pw20_wt;
@@ -723,7 +723,7 @@ static void register_cpu_online(unsigned int cpu)
device_create_file(s, &dev_attr_pir);
#endif /* CONFIG_PPC64 */
-#ifdef CONFIG_FSL_SOC
+#ifdef CONFIG_PPC_FSL_BOOK3E
if (PVR_VER(cur_cpu_spec->pvr_value) == PVR_VER_E6500) {
device_create_file(s, &dev_attr_pw20_state);
device_create_file(s, &dev_attr_pw20_wait_time);
@@ -804,7 +804,7 @@ static void unregister_cpu_online(unsigned int cpu)
device_remove_file(s, &dev_attr_pir);
#endif /* CONFIG_PPC64 */
-#ifdef CONFIG_FSL_SOC
+#ifdef CONFIG_PPC_FSL_BOOK3E
if (PVR_VER(cur_cpu_spec->pvr_value) == PVR_VER_E6500) {
device_remove_file(s, &dev_attr_pw20_state);
device_remove_file(s, &dev_attr_pw20_wait_time);
-Scott
^ permalink raw reply related
* Re: 答复: [v7] clk: corenet: Adds the clock binding
From: Scott Wood @ 2014-01-09 21:19 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Mark Rutland, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <e15511a79a9d4446a826da8d9ceec229@BL2PR03MB115.namprd03.prod.outlook.com>
On Wed, 2014-01-08 at 20:57 -0600, Tang Yuantian-B29983 wrote:
> Thanks for you review.
> See my response inline.
>
> Thanks,
> Yuantian
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: 2014年1月9日 星期四 2:44
> > To: Mark Rutland
> > Cc: Tang Yuantian-B29983; galak@kernel.crashing.org;
> > devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: 答复: [v7] clk: corenet: Adds the clock binding
> >
> > On Wed, 2014-01-08 at 09:30 +0000, Mark Rutland wrote:
> > > On Wed, Jan 08, 2014 at 08:53:56AM +0000, Yuantian Tang wrote:
> > > >
> > > > ________________________________________
> > > > 发件人: Wood Scott-B07421
> > > > 发送时间: 2014年1月8日 8:21
> > > > 收件人: Tang Yuantian-B29983
> > > > 抄送: galak@kernel.crashing.org; mark.rutland@arm.com;
> > > > devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > > > 主题: Re: [v7] clk: corenet: Adds the clock binding
> > > >
> > > > On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
> > > > > +Recommended properties:
> > > > > +- ranges: Allows valid translation between child's address space
> > and
> > > > > + parent's. Must be present if the device has sub-nodes.
> > > > > +- #address-cells: Specifies the number of cells used to represent
> > > > > + physical base addresses. Must be present if the device has
> > > > > + sub-nodes and set to 1 if present
> > > > > +- #size-cells: Specifies the number of cells used to represent
> > > > > + the size of an address. Must be present if the device has
> > > > > + sub-nodes and set to 1 if present
> > > >
> > > > Why are we specifying #address-cells/#size-cells here?
> > > >
> > > > A: it has sub-nodes which have REG property, don't we need to
> > > > specify #address-cells/#size-cells?
> > >
> > > If a node has a reg entry, its parent should have #size-cells and
> > > #address-cells to allow it to be parsed properly.
> >
> > Yes, but why do we need to specify in this binding how many cells there
> > will be, especially since this binding only addresses the clock provider
> > aspect of the clockgen nodes (e.g. it doesn't describe the reg)? Or
> > rather, it's partially describing the non-clock aspect, and doesn't
> > address the clock aspect at all AFAICT.
> >
> First of all, they are not "Required properties", they are optional.
> If present, we should give them a value of 1.
Why does it matter, so long as the values translate properly? It's not
as if you're defining a special reg format. It's not that big of a
deal, but it seems unnecessary.
> Then, yes, this binding describes clockgen node which is "CLOCK BLOCK".
Sorry, I missed where "reg" was documented due to the
required/recommended split.
> > Where does the actual input clock frequency go? U-Boot puts it in the
> > clockgen node itself as clock-frequency, but that isn't described in the
> > binding. How does that relate to the sysclk node? If "fsl,qoriq-sysclk-
> > 1.0" is supposed to indicate that clock-frequency can be found in the
> > parent node, that isn't specified by the binding, nor is clock-frequency
> > shown in the example.
> >
> clock-frequency is a wired property.
Do you mean "weird"?
> It is in clockgen node right now.
> But it should be placed somewhere in clock nodes.
If we were doing this from scratch, yes, but there's existing U-Boot
code that we want to be compatible with.
> If I describe here, I would be asked why it is related to clockgen node?
That's not a good reason to leave it undocumented.
> > What is the difference between "fsl,qoriq-sysclk-1.0" and "fsl,qoriq-
> > sysclk-2.0"? How does the concept of a fixed input clock change?
> >
> Technically, there is no difference between *sysclk-1.0 and *-2.0, just like
> Clockgen-2.0 and 1.0. Naming like this just to indicate they belong to chassis 2.0
> and 1.0 respectively.
I guess it's OK if it encourages people to consider switching to the
standard fixed-clock for future chassis.
So the only thing that really needs to be fixed is the missing
clock-frequency documentation.
-Scott
^ permalink raw reply
* [PATCH] powerpc: fix 8xx and 6xx final link failures
From: Paul Gortmaker @ 2014-01-09 20:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: Paul Gortmaker, linuxppc-dev
As of commit b81f18e55e9f4ea81759bcb00fea295de679bbe8 ("powerpc/boot:
Only build board support files when required.") the two defconfigs
ep88xc_defconfig and storcenter_defconfig would fail final link as
follows:
WRAP arch/powerpc/boot/dtbImage.ep88xc
arch/powerpc/boot/wrapper.a(mpc8xx.o): In function `mpc885_get_clock':
arch/powerpc/boot/mpc8xx.c:30: undefined reference to `fsl_get_immr'
make[1]: *** [arch/powerpc/boot/dtbImage.ep88xc] Error 1
...and...
WRAP arch/powerpc/boot/cuImage.storcenter
arch/powerpc/boot/cuboot-pq2.o: In function `pq2_platform_fixups':
cuboot-pq2.c:(.text+0x324): undefined reference to `fsl_get_immr'
make[1]: *** [arch/powerpc/boot/cuImage.storcenter] Error 1
We need the fsl-soc board files built for these two platforms.
Cc: Tony Breeds <tony@bakeyournoodle.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Fixes: b81f18e55e9f ("powerpc/boot: Only build board support files when required.")
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ca7f08c..4676e55 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -71,9 +71,9 @@ src-wlib-y := string.S crt0.S crtsavres.S stdio.c main.c \
uartlite.c mpc52xx-psc.c
src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
src-wlib-$(CONFIG_44x) += 4xx.c ebony.c bamboo.c
-src-wlib-$(CONFIG_8xx) += mpc8xx.c planetcore.c
+src-wlib-$(CONFIG_8xx) += mpc8xx.c planetcore.c fsl-soc.c
src-wlib-$(CONFIG_PPC_82xx) += pq2.c fsl-soc.c planetcore.c
-src-wlib-$(CONFIG_EMBEDDED6xx) += mv64x60.c mv64x60_i2c.c ugecon.c
+src-wlib-$(CONFIG_EMBEDDED6xx) += mv64x60.c mv64x60_i2c.c ugecon.c fsl-soc.c
src-plat-y := of.c epapr.c
src-plat-$(CONFIG_40x) += fixed-head.S ep405.c cuboot-hotfoot.c \
--
1.8.5.1
^ permalink raw reply related
* Re: [PATCH RFC 2/3] ARM: kernel: add support for cpu cache information
From: Russell King - ARM Linux @ 2014-01-09 20:08 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <52CEF9E7.4070706@arm.com>
On Thu, Jan 09, 2014 at 07:35:03PM +0000, Sudeep Holla wrote:
> I assume you referring to some particular CPUs which don't implement this.
> I could not find it as optional or IMPLEMENTATION defined in ARM ARM.
> I might be missing to find it or there may be exceptions.
> Can you please provide more information on that ?
This is where _not_ relying on the most up to date ARM architecture
reference manual, but instead referring back to the ARM architecture
manual revision appropriate to the architecture is a far better plan.
For example, DDI0100E, Part B, 2.3.2:
| 2.3.2 Cache Type register
| If present, the Cache Type register supplies the following details about
| the cache:
Note the "if present" - it's a fact that not all ARMv4 CPUs support this
register. 2.3 also tells you how to detect when these registers are
implemented:
| ID registers other than the main ID register are defined so that when
| implemented, their value cannot be equal to that of the main ID register.
| Software can therefore determine whether they exist by reading both
| the main ID register and the desired register and comparing their values.
| If the two values are not equal, the desired register exists.
I can go back further to one of the initial revisions of the ARM ARM,
but that's a paper copy.
I can also refer you to DDI0087E (ARM720T) section 4.3 - this is an
ARMv4T CPU, and it has no cache type register. StrongARM is another
example where the CTR is not implemented.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Greg Kroah-Hartman @ 2014-01-09 20:03 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <52CEFCE3.1040701@arm.com>
On Thu, Jan 09, 2014 at 07:47:47PM +0000, Sudeep Holla wrote:
> On 09/01/14 19:31, Greg Kroah-Hartman wrote:
> > On Thu, Jan 09, 2014 at 07:19:00PM +0000, Sudeep Holla wrote:
> >> On 08/01/14 20:27, Greg Kroah-Hartman wrote:
> >>> On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
> >>>> From: Sudeep Holla <sudeep.holla@arm.com>
> >>>>
> >>>> This patch adds initial support for providing processor cache information
> >>>> to userspace through sysfs interface. This is based on x86 implementation
> >>>> and hence the interface is intended to be fully compatible.
> >>>>
> >>>> A per-cpu array of cache information maintained is used mainly for
> >>>> sysfs-related book keeping.
> >>>>
> >>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >>>> ---
> >>>> drivers/base/Makefile | 2 +-
> >>>> drivers/base/cacheinfo.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++
> >>>> include/linux/cacheinfo.h | 43 +++++++
> >>>> 3 files changed, 340 insertions(+), 1 deletion(-)
> >>>> create mode 100644 drivers/base/cacheinfo.c
> >>>> create mode 100644 include/linux/cacheinfo.h
> >>>>
> >>>> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> >>>> index 94e8a80..76f07c8 100644
> >>>> --- a/drivers/base/Makefile
> >>>> +++ b/drivers/base/Makefile
> >>>> @@ -4,7 +4,7 @@ obj-y := core.o bus.o dd.o syscore.o \
> >>>> driver.o class.o platform.o \
> >>>> cpu.o firmware.o init.o map.o devres.o \
> >>>> attribute_container.o transport_class.o \
> >>>> - topology.o
> >>>> + topology.o cacheinfo.o
> >>>> obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
> >>>> obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
> >>>> obj-y += power/
> >>>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> >>>> new file mode 100644
> >>>> index 0000000..f436c31
> >>>> --- /dev/null
> >>>> +++ b/drivers/base/cacheinfo.c
> >>>> @@ -0,0 +1,296 @@
> >>>> +/*
> >>>> + * cacheinfo support - processor cache information via sysfs
> >>>> + *
> >>>> + * Copyright (C) 2013 ARM Ltd.
> >>>> + * All Rights Reserved
> >>>> + *
> >>>> + * Author: Sudeep Holla <sudeep.holla@arm.com>
> >>>> + *
> >>>> + * This program is free software; you can redistribute it and/or modify
> >>>> + * it under the terms of the GNU General Public License version 2 as
> >>>> + * published by the Free Software Foundation.
> >>>> + *
> >>>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> >>>> + * kind, whether express or implied; without even the implied warranty
> >>>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>>> + * GNU General Public License for more details.
> >>>> + */
> >>>> +#include <linux/bitops.h>
> >>>> +#include <linux/cacheinfo.h>
> >>>> +#include <linux/compiler.h>
> >>>> +#include <linux/cpu.h>
> >>>> +#include <linux/device.h>
> >>>> +#include <linux/init.h>
> >>>> +#include <linux/kobject.h>
> >>>> +#include <linux/of.h>
> >>>> +#include <linux/sched.h>
> >>>> +#include <linux/slab.h>
> >>>> +#include <linux/smp.h>
> >>>> +#include <linux/sysfs.h>
> >>>> +
> >>>> +struct cache_attr {
> >>>> + struct attribute attr;
> >>>> + ssize_t(*show) (unsigned int, unsigned short, char *);
> >>>> + ssize_t(*store) (unsigned int, unsigned short, const char *, size_t);
> >>>> +};
> >>>> +
> >>>> +/* pointer to kobject for cpuX/cache */
> >>>> +static DEFINE_PER_CPU(struct kobject *, ci_cache_kobject);
> >>>> +#define per_cpu_cache_kobject(cpu) (per_cpu(ci_cache_kobject, cpu))
> >>>> +
> >>>> +struct index_kobject {
> >>>> + struct kobject kobj;
> >>>> + unsigned int cpu;
> >>>> + unsigned short index;
> >>>> +};
> >>>> +
> >>>> +static cpumask_t cache_dev_map;
> >>>> +
> >>>> +/* pointer to array of kobjects for cpuX/cache/indexY */
> >>>
> >>> Please don't use "raw" kobjects for this, use the device attribute
> >>> groups, that's what they are there for. Bonus is that your code should
> >>> get a lot simpler when you do that.
> >>>
> >>
> >> Yes I now understand device attribute group simplifies the code, but I think
> >> kobjects are still needed as we need to track both cpu and cache index.
> >> By reusing only cpu device kobject, we can track cpu only.
> >
> > I don't understand, you are putting things under the cpu device object,
> > why do you care about a "cache" kobject?
> >
> Yes though the cache attributes are under cpu objects, it's hierarchical
> something like:
> /sys/devices/system/cpu/cpu<n>/cache/index<m>/<attribute_x>
> <attribute_x> is unique for each pair of (cpu<n>, index<m>
> index is more like cache level, but with 2 indices if they are separate(I$,D$)
Then make the "cache" a struct device, and then create the attribute
group under that? You'll want that anyway as you don't have any
visibility to userspace tools by using raw kobjects, they don't see them
at all (i.e. libudev and the like.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Sudeep Holla @ 2014-01-09 19:47 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org, Sudeep.Holla,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140109193121.GA14991@kroah.com>
On 09/01/14 19:31, Greg Kroah-Hartman wrote:
> On Thu, Jan 09, 2014 at 07:19:00PM +0000, Sudeep Holla wrote:
>> On 08/01/14 20:27, Greg Kroah-Hartman wrote:
>>> On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
>>>> From: Sudeep Holla <sudeep.holla@arm.com>
>>>>
>>>> This patch adds initial support for providing processor cache informat=
ion
>>>> to userspace through sysfs interface. This is based on x86 implementat=
ion
>>>> and hence the interface is intended to be fully compatible.
>>>>
>>>> A per-cpu array of cache information maintained is used mainly for
>>>> sysfs-related book keeping.
>>>>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>> drivers/base/Makefile | 2 +-
>>>> drivers/base/cacheinfo.c | 296 +++++++++++++++++++++++++++++++++++++=
+++++++++
>>>> include/linux/cacheinfo.h | 43 +++++++
>>>> 3 files changed, 340 insertions(+), 1 deletion(-)
>>>> create mode 100644 drivers/base/cacheinfo.c
>>>> create mode 100644 include/linux/cacheinfo.h
>>>>
>>>> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
>>>> index 94e8a80..76f07c8 100644
>>>> --- a/drivers/base/Makefile
>>>> +++ b/drivers/base/Makefile
>>>> @@ -4,7 +4,7 @@ obj-y=09=09=09:=3D core.o bus.o dd.o syscore.o \
>>>> =09=09=09 driver.o class.o platform.o \
>>>> =09=09=09 cpu.o firmware.o init.o map.o devres.o \
>>>> =09=09=09 attribute_container.o transport_class.o \
>>>> -=09=09=09 topology.o
>>>> +=09=09=09 topology.o cacheinfo.o
>>>> obj-$(CONFIG_DEVTMPFS)=09+=3D devtmpfs.o
>>>> obj-$(CONFIG_DMA_CMA) +=3D dma-contiguous.o
>>>> obj-y=09=09=09+=3D power/
>>>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>>>> new file mode 100644
>>>> index 0000000..f436c31
>>>> --- /dev/null
>>>> +++ b/drivers/base/cacheinfo.c
>>>> @@ -0,0 +1,296 @@
>>>> +/*
>>>> + * cacheinfo support - processor cache information via sysfs
>>>> + *
>>>> + * Copyright (C) 2013 ARM Ltd.
>>>> + * All Rights Reserved
>>>> + *
>>>> + * Author: Sudeep Holla <sudeep.holla@arm.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modi=
fy
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>>>> + * kind, whether express or implied; without even the implied warrant=
y
>>>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + */
>>>> +#include <linux/bitops.h>
>>>> +#include <linux/cacheinfo.h>
>>>> +#include <linux/compiler.h>
>>>> +#include <linux/cpu.h>
>>>> +#include <linux/device.h>
>>>> +#include <linux/init.h>
>>>> +#include <linux/kobject.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/sched.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/smp.h>
>>>> +#include <linux/sysfs.h>
>>>> +
>>>> +struct cache_attr {
>>>> +=09struct attribute attr;
>>>> +=09 ssize_t(*show) (unsigned int, unsigned short, char *);
>>>> +=09 ssize_t(*store) (unsigned int, unsigned short, const char *, size=
_t);
>>>> +};
>>>> +
>>>> +/* pointer to kobject for cpuX/cache */
>>>> +static DEFINE_PER_CPU(struct kobject *, ci_cache_kobject);
>>>> +#define per_cpu_cache_kobject(cpu) (per_cpu(ci_cache_kobject, cpu=
))
>>>> +
>>>> +struct index_kobject {
>>>> +=09struct kobject kobj;
>>>> +=09unsigned int cpu;
>>>> +=09unsigned short index;
>>>> +};
>>>> +
>>>> +static cpumask_t cache_dev_map;
>>>> +
>>>> +/* pointer to array of kobjects for cpuX/cache/indexY */
>>>
>>> Please don't use "raw" kobjects for this, use the device attribute
>>> groups, that's what they are there for. Bonus is that your code should
>>> get a lot simpler when you do that.
>>>
>>
>> Yes I now understand device attribute group simplifies the code, but I t=
hink
>> kobjects are still needed as we need to track both cpu and cache index.
>> By reusing only cpu device kobject, we can track cpu only.
>=20
> I don't understand, you are putting things under the cpu device object,
> why do you care about a "cache" kobject?
>=20
Yes though the cache attributes are under cpu objects, it's hierarchical
something like:
/sys/devices/system/cpu/cpu<n>/cache/index<m>/<attribute_x>
<attribute_x> is unique for each pair of (cpu<n>, index<m>
index is more like cache level, but with 2 indices if they are separate(I$,=
D$)
>> One thought I have is to make cache_info structure common to all archite=
cture
>> (for now its ARM specific) and introduce kobject in that similar to ia64
>> implementation. That even eliminates lot of weak functions defined.
>=20
> Please don't use raw kobjects if at all possible, it's not good for a
> variety of reasons (no userspace events, have to roll your own code,
> etc.)
>=20
Yes I understand, will try to explore other feasible solutions.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH RFC 2/3] ARM: kernel: add support for cpu cache information
From: Sudeep Holla @ 2014-01-09 19:35 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman,
Sudeep.Holla, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140108205754.GN27432@n2100.arm.linux.org.uk>
On 08/01/14 20:57, Russell King - ARM Linux wrote:
> On Wed, Jan 08, 2014 at 07:26:07PM +0000, Sudeep Holla wrote:
>> +#if __LINUX_ARM_ARCH__ < 7 /* pre ARMv7 */
>> +
>> +#define MAX_CACHE_LEVEL=09=091=09/* Only 1 level supported */
>> +#define CTR_CTYPE_SHIFT=09=0924
>> +#define CTR_CTYPE_MASK=09=09(1 << CTR_CTYPE_SHIFT)
>> +
>> +static inline unsigned int get_ctr(void)
>> +{
>> +=09unsigned int ctr;
>> +=09asm volatile ("mrc p15, 0, %0, c0, c0, 1" : "=3Dr" (ctr));
>> +=09return ctr;
>> +}
>> +
>> +static enum cache_type get_cache_type(int level)
>> +{
>> +=09if (level > MAX_CACHE_LEVEL)
>> +=09=09return CACHE_TYPE_NOCACHE;
>> +=09return get_ctr() & CTR_CTYPE_MASK ?
>> +=09=09CACHE_TYPE_SEPARATE : CACHE_TYPE_UNIFIED;
>=20
> So, what do we do for CPUs that don't implement the CTR? Just return
> random rubbish based on decoding the CPU Identity register as if it
> were the cache type register?
>=20
I assume you referring to some particular CPUs which don't implement this.
I could not find it as optional or IMPLEMENTATION defined in ARM ARM.
I might be missing to find it or there may be exceptions.
Can you please provide more information on that ?
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Greg Kroah-Hartman @ 2014-01-09 19:31 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <52CEF624.9020702@arm.com>
On Thu, Jan 09, 2014 at 07:19:00PM +0000, Sudeep Holla wrote:
> On 08/01/14 20:27, Greg Kroah-Hartman wrote:
> > On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
> >> From: Sudeep Holla <sudeep.holla@arm.com>
> >>
> >> This patch adds initial support for providing processor cache information
> >> to userspace through sysfs interface. This is based on x86 implementation
> >> and hence the interface is intended to be fully compatible.
> >>
> >> A per-cpu array of cache information maintained is used mainly for
> >> sysfs-related book keeping.
> >>
> >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >> ---
> >> drivers/base/Makefile | 2 +-
> >> drivers/base/cacheinfo.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++
> >> include/linux/cacheinfo.h | 43 +++++++
> >> 3 files changed, 340 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/base/cacheinfo.c
> >> create mode 100644 include/linux/cacheinfo.h
> >>
> >> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> >> index 94e8a80..76f07c8 100644
> >> --- a/drivers/base/Makefile
> >> +++ b/drivers/base/Makefile
> >> @@ -4,7 +4,7 @@ obj-y := core.o bus.o dd.o syscore.o \
> >> driver.o class.o platform.o \
> >> cpu.o firmware.o init.o map.o devres.o \
> >> attribute_container.o transport_class.o \
> >> - topology.o
> >> + topology.o cacheinfo.o
> >> obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
> >> obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
> >> obj-y += power/
> >> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> >> new file mode 100644
> >> index 0000000..f436c31
> >> --- /dev/null
> >> +++ b/drivers/base/cacheinfo.c
> >> @@ -0,0 +1,296 @@
> >> +/*
> >> + * cacheinfo support - processor cache information via sysfs
> >> + *
> >> + * Copyright (C) 2013 ARM Ltd.
> >> + * All Rights Reserved
> >> + *
> >> + * Author: Sudeep Holla <sudeep.holla@arm.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> >> + * kind, whether express or implied; without even the implied warranty
> >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + */
> >> +#include <linux/bitops.h>
> >> +#include <linux/cacheinfo.h>
> >> +#include <linux/compiler.h>
> >> +#include <linux/cpu.h>
> >> +#include <linux/device.h>
> >> +#include <linux/init.h>
> >> +#include <linux/kobject.h>
> >> +#include <linux/of.h>
> >> +#include <linux/sched.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/smp.h>
> >> +#include <linux/sysfs.h>
> >> +
> >> +struct cache_attr {
> >> + struct attribute attr;
> >> + ssize_t(*show) (unsigned int, unsigned short, char *);
> >> + ssize_t(*store) (unsigned int, unsigned short, const char *, size_t);
> >> +};
> >> +
> >> +/* pointer to kobject for cpuX/cache */
> >> +static DEFINE_PER_CPU(struct kobject *, ci_cache_kobject);
> >> +#define per_cpu_cache_kobject(cpu) (per_cpu(ci_cache_kobject, cpu))
> >> +
> >> +struct index_kobject {
> >> + struct kobject kobj;
> >> + unsigned int cpu;
> >> + unsigned short index;
> >> +};
> >> +
> >> +static cpumask_t cache_dev_map;
> >> +
> >> +/* pointer to array of kobjects for cpuX/cache/indexY */
> >
> > Please don't use "raw" kobjects for this, use the device attribute
> > groups, that's what they are there for. Bonus is that your code should
> > get a lot simpler when you do that.
> >
>
> Yes I now understand device attribute group simplifies the code, but I think
> kobjects are still needed as we need to track both cpu and cache index.
> By reusing only cpu device kobject, we can track cpu only.
I don't understand, you are putting things under the cpu device object,
why do you care about a "cache" kobject?
> One thought I have is to make cache_info structure common to all architecture
> (for now its ARM specific) and introduce kobject in that similar to ia64
> implementation. That even eliminates lot of weak functions defined.
Please don't use raw kobjects if at all possible, it's not good for a
variety of reasons (no userspace events, have to roll your own code,
etc.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Sudeep Holla @ 2014-01-09 19:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org, Sudeep.Holla,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140108202707.GE8417@kroah.com>
On 08/01/14 20:27, Greg Kroah-Hartman wrote:
> On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
>> From: Sudeep Holla <sudeep.holla@arm.com>
>>
>> This patch adds initial support for providing processor cache informatio=
n
>> to userspace through sysfs interface. This is based on x86 implementatio=
n
>> and hence the interface is intended to be fully compatible.
>>
>> A per-cpu array of cache information maintained is used mainly for
>> sysfs-related book keeping.
>>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/base/Makefile | 2 +-
>> drivers/base/cacheinfo.c | 296 +++++++++++++++++++++++++++++++++++++++=
+++++++
>> include/linux/cacheinfo.h | 43 +++++++
>> 3 files changed, 340 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/base/cacheinfo.c
>> create mode 100644 include/linux/cacheinfo.h
>>
>> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
>> index 94e8a80..76f07c8 100644
>> --- a/drivers/base/Makefile
>> +++ b/drivers/base/Makefile
>> @@ -4,7 +4,7 @@ obj-y=09=09=09:=3D core.o bus.o dd.o syscore.o \
>> =09=09=09 driver.o class.o platform.o \
>> =09=09=09 cpu.o firmware.o init.o map.o devres.o \
>> =09=09=09 attribute_container.o transport_class.o \
>> -=09=09=09 topology.o
>> +=09=09=09 topology.o cacheinfo.o
>> obj-$(CONFIG_DEVTMPFS)=09+=3D devtmpfs.o
>> obj-$(CONFIG_DMA_CMA) +=3D dma-contiguous.o
>> obj-y=09=09=09+=3D power/
>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> new file mode 100644
>> index 0000000..f436c31
>> --- /dev/null
>> +++ b/drivers/base/cacheinfo.c
>> @@ -0,0 +1,296 @@
>> +/*
>> + * cacheinfo support - processor cache information via sysfs
>> + *
>> + * Copyright (C) 2013 ARM Ltd.
>> + * All Rights Reserved
>> + *
>> + * Author: Sudeep Holla <sudeep.holla@arm.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include <linux/bitops.h>
>> +#include <linux/cacheinfo.h>
>> +#include <linux/compiler.h>
>> +#include <linux/cpu.h>
>> +#include <linux/device.h>
>> +#include <linux/init.h>
>> +#include <linux/kobject.h>
>> +#include <linux/of.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/smp.h>
>> +#include <linux/sysfs.h>
>> +
>> +struct cache_attr {
>> +=09struct attribute attr;
>> +=09 ssize_t(*show) (unsigned int, unsigned short, char *);
>> +=09 ssize_t(*store) (unsigned int, unsigned short, const char *, size_t=
);
>> +};
>> +
>> +/* pointer to kobject for cpuX/cache */
>> +static DEFINE_PER_CPU(struct kobject *, ci_cache_kobject);
>> +#define per_cpu_cache_kobject(cpu) (per_cpu(ci_cache_kobject, cpu))
>> +
>> +struct index_kobject {
>> +=09struct kobject kobj;
>> +=09unsigned int cpu;
>> +=09unsigned short index;
>> +};
>> +
>> +static cpumask_t cache_dev_map;
>> +
>> +/* pointer to array of kobjects for cpuX/cache/indexY */
>=20
> Please don't use "raw" kobjects for this, use the device attribute
> groups, that's what they are there for. Bonus is that your code should
> get a lot simpler when you do that.
>=20
Yes I now understand device attribute group simplifies the code, but I thin=
k
kobjects are still needed as we need to track both cpu and cache index.
By reusing only cpu device kobject, we can track cpu only.
Please correct me if I am missing to understand something here.
One thought I have is to make cache_info structure common to all architectu=
re
(for now its ARM specific) and introduce kobject in that similar to ia64
implementation. That even eliminates lot of weak functions defined.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Sudeep Holla @ 2014-01-09 19:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org, Sudeep.Holla,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140108202826.GF8417@kroah.com>
On 08/01/14 20:28, Greg Kroah-Hartman wrote:
> On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
>> From: Sudeep Holla <sudeep.holla@arm.com>
>> +#define define_one_ro(_name) \
>> +static struct cache_attr _name =3D \
>> +=09__ATTR(_name, 0444, show_##_name, NULL)
>=20
> In the future, we do have __ATTR_RO(), which should be used instead.
> You should never use __ATTR() on it's own, if at all possible. I'm
> sweeping the tree for all usages and fixing them slowly up over time.
>=20
Understood, will fix it.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Sudeep Holla @ 2014-01-09 19:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devicetree@vger.kernel.org, Ashok Raj, Rob Herring,
x86@kernel.org, linux-kernel@vger.kernel.org, Sudeep.Holla,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140108202613.GD8417@kroah.com>
On 08/01/14 20:26, Greg Kroah-Hartman wrote:
> On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
>> From: Sudeep Holla <sudeep.holla@arm.com>
>>
>> This patch adds initial support for providing processor cache informatio=
n
>> to userspace through sysfs interface. This is based on x86 implementatio=
n
>> and hence the interface is intended to be fully compatible.
>>
>> A per-cpu array of cache information maintained is used mainly for
>> sysfs-related book keeping.
>>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/base/Makefile | 2 +-
>> drivers/base/cacheinfo.c | 296 +++++++++++++++++++++++++++++++++++++++=
+++++++
>> include/linux/cacheinfo.h | 43 +++++++
>> 3 files changed, 340 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/base/cacheinfo.c
>> create mode 100644 include/linux/cacheinfo.h
>=20
> You are creating sysfs files, yet you didn't add Documentation/ABI/
> information, which is required. Please fix that.
>=20
Ah, I overlooked it. But I am not creating any new sysfs files in this seri=
es.
I am just trying to unify duplicated code in various architectures.
Since these sysfs files are already created in:
1. arch/ia64/kernel/topology.c
2. arch/powerpc/kernel/cacheinfo.c
3. arch/s390/kernel/cache.c
4. arch/x86/kernel/cpu/intel_cacheinfo.c and
also already used by user-space tools like `lscpu` I assumed it's already
documented.
I will add it in next version.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl_esai: Add ESAI CPU DAI driver
From: Mark Brown @ 2014-01-09 18:44 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, shawn.guo, pawel.moll,
ijc+devicetree, tiwai, linux-kernel, linux-doc, timur, lgirdwood,
robh+dt, rob, galak, grant.likely, perex, linuxppc-dev
In-Reply-To: <1389265078-16256-1-git-send-email-Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Thu, Jan 09, 2014 at 06:57:58PM +0800, Nicolin Chen wrote:
> +/**
> + * This function configures the ratio between MCLK (HCK) and BCLK (SCK)
> + * (For DAI Master Mode only)
> + *
> + * Note: Machine driver should calculate the ratio to call this function.
> + * Only effective after calling set_dai_sysclk() to set HCK direction.
> + */
> +static int fsl_esai_set_bclk_ratio(struct snd_soc_dai *dai, unsigned int ratio)
Why does the machine driver have to do this by hand, being able to
override is fine but having sensible defaults is easier? Or does it
actually do that and the comment just needs updating?
> + ret = devm_snd_soc_register_component(&pdev->dev, &fsl_esai_component,
> + &fsl_esai_dai, 1);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to register DAI: %d\n", ret);
> + return ret;
> + }
> +
> + ret = imx_pcm_dma_init(pdev);
> + if (ret)
> + dev_err(&pdev->dev, "failed to init imx pcm dma: %d\n", ret);
> +
> + /* Reset ESAI unit */
> + regmap_write(esai_priv->regmap, REG_ESAI_ECR, ESAI_ECR_ERST);
> +
> + /*
> + * We need to enable ESAI so as to access some of its registers.
> + * Otherwise, we would fail to dump regmap from user space.
> + */
> + regmap_write(esai_priv->regmap, REG_ESAI_ECR, ESAI_ECR_ESAIEN);
I would expect to see the hardware initialisation before we start
registering with the core otherwise the core might start trying to run
prior to the hardware being initialised.
Otherwise this looks good.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl_ssi: Set default slot number for common cases
From: Mark Brown @ 2014-01-09 17:34 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel, lgirdwood, tiwai, festevam, timur, perex,
linuxppc-dev
In-Reply-To: <1389264168-13379-1-git-send-email-Guangyu.Chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Thu, Jan 09, 2014 at 06:42:48PM +0800, Nicolin Chen wrote:
> For those platforms using DAI master mode like I2S, it's better to pre-set
> a default slot number so that there's no need for these common cases to set
> the slot number from its machine driver any more.
Applied, thanks - but note that this will mean anything that does want
non-default TDM will need to set it every single time it runs rather
than being able to do it once on init. This might need revisiting if
there are users doing that.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH -next] ASoC: fsl-ssi: Add missing clk_disable_unprepare() on error in fsl_ssi_probe()
From: Mark Brown @ 2014-01-09 17:26 UTC (permalink / raw)
To: Wei Yongjun
Cc: alsa-devel, lgirdwood, tiwai, timur, perex, yongjun_wei, robh+dt,
grant.likely, linuxppc-dev
In-Reply-To: <CAPgLHd-wvDcOz1Ne69g3o4b=VS7jaPU5Gu4DBMq_tBCsY0xcew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
On Thu, Jan 09, 2014 at 10:27:31PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing clk_disable_unprepare() before return from
> fsl_ssi_probe() in the request irq error handling case.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()
From: Alexander Graf @ 2014-01-09 15:29 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm@vger.kernel.org mailing list, kvm-ppc
In-Reply-To: <1389279665-20970-1-git-send-email-mihai.caraman@freescale.com>
On 09.01.2014, at 16:01, Mihai Caraman <mihai.caraman@freescale.com> wrote:
> Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss().
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Thanks, applied to kvm-ppc-queue.
Alex
^ permalink raw reply
* [PATCH] KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()
From: Mihai Caraman @ 2014-01-09 15:01 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss().
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kvm/e500_mmu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index ebca6b8..50860e9 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -127,7 +127,7 @@ static int kvmppc_e500_tlb_index(struct kvmppc_vcpu_e500 *vcpu_e500,
}
static inline void kvmppc_e500_deliver_tlb_miss(struct kvm_vcpu *vcpu,
- unsigned int eaddr, int as)
+ gva_t eaddr, int as)
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
unsigned int victim, tsized;
--
1.7.3.4
^ permalink raw reply related
* [PATCH -next] ASoC: fsl-ssi: Add missing clk_disable_unprepare() on error in fsl_ssi_probe()
From: Wei Yongjun @ 2014-01-09 14:27 UTC (permalink / raw)
To: timur, lgirdwood, broonie, perex, tiwai, grant.likely, robh+dt
Cc: yongjun_wei, linuxppc-dev, alsa-devel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add the missing clk_disable_unprepare() before return from
fsl_ssi_probe() in the request irq error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
sound/soc/fsl/fsl_ssi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index e18b4b3..4c6818d 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1464,7 +1464,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
if (ret < 0) {
dev_err(&pdev->dev, "could not claim irq %u\n",
ssi_private->irq);
- goto error_irqmap;
+ goto error_clk;
}
}
^ permalink raw reply related
* Re: [PATCH RFC v6 4/5] dma: mpc512x: register for device tree channel lookup
From: Vinod Koul @ 2014-01-09 11:19 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Lars-Peter Clausen, Arnd Bergmann, Alexander Popov, dmaengine,
Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20140108164719.GO20094@book.gsilab.sittig.org>
On Wed, Jan 08, 2014 at 05:47:19PM +0100, Gerhard Sittig wrote:
> [ dropping devicetree from the Cc: list ]
>
> [ what is the semantics of DMA_PRIVATE capability flag?
> is documentation available beyond the initial commit message?
> need individual channels be handled instead of controllers? ]
The DMA_PRIVATE means that your channels are not to be used for global memcpy,
as one can do in async cases (this is hwere DMAengine came into existence)
If the device has the capablity of doing genric memcpy then it should not set
this. For slave dma usage the dam channel can transfer data to a specfic
slave device(s), hence we should use this is geric fashion so setting
DMA_PRIVATE makes sense in those cases.
>
> On Sat, Jan 04, 2014 at 00:54 +0400, Alexander Popov wrote:
> >
> > Hello Gerhard.
> > Thanks for your review.
> >
> > 2013/12/26 Gerhard Sittig <gsi@denx.de>:
> > > [ dropping devicetree, we're DMA specific here ]
> > >
> > > On Tue, Dec 24, 2013 at 16:06 +0400, Alexander Popov wrote:
> > >>
> > >> --- a/drivers/dma/mpc512x_dma.c
> > >> +++ b/drivers/dma/mpc512x_dma.c
> > >> [ ... ]
> > >> @@ -950,6 +951,7 @@ static int mpc_dma_probe(struct platform_device *op)
> > >> INIT_LIST_HEAD(&dma->channels);
> > >> dma_cap_set(DMA_MEMCPY, dma->cap_mask);
> > >> dma_cap_set(DMA_SLAVE, dma->cap_mask);
> > >> + dma_cap_set(DMA_PRIVATE, dma->cap_mask);
> > >>
> > >> for (i = 0; i < dma->chancnt; i++) {
> > >> mchan = &mdma->channels[i];
> > >
> > > What are the implications of this? Is a comment due?
> >
> > I've involved DMA_PRIVATE flag because new of_dma_xlate_by_chan_id()
> > uses dma_get_slave_channel() instead of dma_request_channel()
> > (PATCH RFC v6 3/5). This flag is implicitly set in dma_request_channel(),
> > but is not set in dma_get_slave_channel().
Which makes me thing you are targetting slave usages. Do you intend to use for
mempcy too on all controllers you support. in that case you should set it
selectively.
> > There are only two places in the mainline kernel, where
> > dma_get_slave_channel() is used. I've picked up the idea
> > at one of these places. Please look at this patch:
> > http://www.spinics.net/lists/arm-kernel/msg268718.html
>
> I agree that the change looks simple, and there is no doubt that
> other drivers apply the flag. None of this I questioned. Yet
> I'm afraid that the implications are rather huge.
>
> Unless I miss something, I'd happily learn where I'm wrong.
>
> > > I haven't found documentation about the DMA_PRIVATE flag, only
> > > saw commit 59b5ec21446b9 "dmaengine: introduce
> > > dma_request_channel and private channels".
> >
> > Unfortunately I didn't find any description of DMA_PRIVATE flag too.
> > But the comment at the beginning of drivers/dma/dmaengine.c
> > may give a clue. Quotation:
> > * subsystem can get access to a channel by calling dmaengine_get() followed
> > * by dma_find_channel(), or if it has need for an exclusive channel
> > it can call
> > * dma_request_channel(). Once a channel is allocated a reference is taken
> > * against its corresponding driver to disable removal.
> >
> > DMA_PRIVATE capability flag might indicate that the DMA controller
> > can provide exclusive channels to its clients. Please correct me if I'm wrong.
> >
> > > Alex, unless I'm
> > > missing something this one-line change is quite a change in
> > > semantics, and has dramatic influence on the code's behaviour
> > > (ignores the DMA controller when looking for channels that can do
> > > mem-to-mem transfers)
> >
> > Excuse me, Gerhard, I don't see what you mean.
> > Could you point to the corresponding code?
>
> You did see `git show 59b5ec21446b9`, didn't you? The commit
> message strongly suggests that DMA_PRIVATE applies to the whole
> DMA controller and excludes _all_ of its channels from the
> general purpose allocator which mem-to-mem transfers appear to be
> using. It's not just a hint, but an active decision to reject
> requests.
>
> Not only checking code references, but doing a text search,
> reveals one more comment on the DMA_PRIVATE flag in a crypto
> related document, which supports my interpretation:
> Documentation/crypto/async-tx-api.txt:203
>
>
> Can somebody ACK or NAK my interpretation? Dan, you committed
> this change which introduced the DMA_PRIVATE logic. What was the
> motivation for it, or the goal to achieve? Do other platforms
> have several dedicated DMA controllers, some for peripherals and
> some for memory transfers? Should the "private" flag apply to
> channels and not whole controllers? Am I over-estimating the
> benefit or importance of DMA supported memory transfers?
The DMA_PRIVATE flag is more on how the channel is allocated and will it be used
by generic allocator or not. You cna still use mecpy ops for a controller with
DMA_PRIVATE flag if the controller supports.
>
>
> Still I see a difference in the lookup approaches: Yours applies
> DMA_PRIVATE globally and in advance, preventing _any_ use of DMA
> for memory transfers. While the __dma_request_channel() routine
> only applies it _temporarily_ around a dma_chan_get() operation.
> Allowing for use of DMA channels by both individual peripherals
> as well as memory transfers.
>
No it doesnt prevent. You can still use it for memcpy once you have the channel.
--
~Vinod
>
> > > Consider the fact that this driver
> > > handles both MPC5121 as well as MPC8308 hardware.
> >
> > Ah, yes, sorry. I should certainly fix this, if setting of DMA_PRIVATE flag
> > is needed at all.
>
> What I meant here is that implications for all affected platforms
> should be considered. There is one driver source, but the driver
> applies to more than one platform (another issue of the driver is
> that this is not apparent from the doc nor the compat strings).
>
> MPC512x has one (GP) DMA controller, of which one channel is
> dedicated to DDR, and all other channels can get used for memory
> transfers as well. In addition to most channels being connected
> to a specific peripheral for flow control. Which your patch set
> introduces initial support for.
>
> MPC8308 has _all_ channels for memory transfers exclusively (or
> at least none of its channels supports flow control).
>
> So blocking memory transfers in mpc512x_dma.c is a total breakage
> for MPC8308 (removes the only previous feature and adds nothing),
> and is a regression for MPC512x (removes the previously supported
> memory transfers, while it may add peripheral supports with very
> few users).
>
>
> virtually yours
> Gerhard Sittig
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox