On Wed, Jun 15, 2016 at 10:16:27AM +0100, Srinivas Kandagatla wrote:
On 14/06/16 16:59, Mark Brown wrote:
On Fri, Jun 10, 2016 at 07:18:45PM +0100, Srinivas Kandagatla wrote:
+config SND_SOC_MSM8916_WCD
- tristate "Qualcomm MSM8916 WCD"
- depends on SPMI && MFD_SYSCON
Normally users select MFD_SYSCON.
This driver is child of spmi bus so, we need SPMI dependency here along with SYSCON.
That does not seem relevant to the problem with depending on MFD_SYSCON.
+#include "msm8916-wcd-registers.h" +#include "msm8916-wcd.h" +#include "dt-bindings/sound/msm8916-wcd.h"
What's in here? There weren't any constants in the bindings.
Yes, there are DAI id's which are used in device trees.
That doesn't make them present in the binding document...
Why is this one device and not two devices? The description indicated that this was two separate bits of silicon.
In theory there are 3 devices, one is the pmic-spmi driver, which provides regmap access to analog part of codec registers. second is syscon driver which provides regmap access to digital parts of codec to codec driver. third is the codec driver which uses both the above.
Codec registers range is just split into two, range 0x0- 0x200 sits in pmic address space and range 0x201 - 0x4ff in the SOC address space,
Are there any other better ways to model this kinda driver?
Why not just have separate devices for each of the register maps?
+static const struct of_device_id msm8916_wcd_match_table[] = {
- {.compatible = "qcom,msm8916-pmic-wcd-codec"},
- {}
+};
We were peering inside the parent for the register map, why does this
I think that's the only way/interface to access PMIC spmi registers I guess.
Don't guess, understand what the code is doing.
appear in the device tree as a separate device? Both the patch
This node is child of spmi bus, like the other spmi devices.
If this is a SPMI device it needs to register a SPMI device not a platform device.