devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sagar Dharia <sdharia@codeaurora.org>
To: Rob Herring <robherring2@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	bp@suse.de, poeschel@lemonage.de,
	Thierry Reding <treding@nvidia.com>,
	Mark Brown <broonie@kernel.org>,
	gong.chen@linux.intel.com, andreas.noever@gmail.com,
	Alan Cox <alan@linux.intel.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	daniel@ffwll.ch, oded.gabbay@amd.com, jkosina@suse.cz,
	sharon.dvir1@mail.huji.ac.il, Joe Perches <joe@perches.com>,
	David Miller <davem@davemloft.net>,
	James Hogan <james.hogan@imgtec.com>,
	michael.opdenacker@free-electrons.com,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kheitke@aud
Subject: Re: [PATCH V3 2/6] of/slimbus: OF helper for SLIMbus
Date: Thu, 6 Aug 2015 13:10:54 -0600	[thread overview]
Message-ID: <55C3B13E.3050108@codeaurora.org> (raw)
In-Reply-To: <CAL_JsqLDzLXR5aC__YhCUzGzVcVYcv_H7QS6zG0vezQPST_Y2Q@mail.gmail.com>

Hello Rob,
On 8/3/2015 10:13 AM, Rob Herring wrote:
> On Mon, Aug 3, 2015 at 1:59 AM, Sagar Dharia <sdharia@codeaurora.org> wrote:
>> OF helper routine scans the SLIMbus DeviceTree, allocates resources,
>> and creates slim_devices according to the hierarchy.
>>
>> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
>> ---
>>   Documentation/devicetree/bindings/slimbus/bus.txt | 46 ++++++++++++++
>>   drivers/slimbus/slim-core.c                       | 75 +++++++++++++++++++++++
>>   2 files changed, 121 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/slimbus/bus.txt b/Documentation/devicetree/bindings/slimbus/bus.txt
>> new file mode 100644
>> index 0000000..a79ed7a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/slimbus/bus.txt
>> @@ -0,0 +1,46 @@
>> +SLIM(Serial Low Power Interchip Media Bus) bus
>> +
>> +SLIMbus is a 2-wire bus, and is used to communicate with peripheral
>> +components like audio-codec.
>> +
>> +Controller is a normal device using binding for whatever bus it is
>> +on (e.g. platform bus).
>> +Required property for SLIMbus controller node:
>> +- compatible   - name of SLIMbus controller following generic names
>> +               recommended practice.
>> +- #address-cells - should be 6 (number of cells required to define
>> +               enumeration address of the device on SLIMbus)
>> +- #size-cells  - should be 0
>> +
>> +No other properties are required in the SLIMbus controller bus node.
>> +
>> +Child nodes:
>> +Every SLIMbus controller node can contain zero or more child nodes
>> +representing slave devices on the bus. Every SLIMbus slave device is
>> +uniquely determined by the 6 byte enumeration address.
>> +
>> +Required property for SLIMbus child node:
>> +- reg          - 6 byte enumeration address of the slave
> 6 cell... I don't think it is a big deal to use 6 words to store 6
> bytes, but is there some reason not to pack the address into 2 cells?
Since the device-enumeration address has 4 logical components, I will 
split this in 4 cells if that's okay.
>
>> +
>> +Optional:
>> +- compatible   - Slave devices can use compatible field to have a name.
>> +               If this field is missing, name of the device will be
>> +               determined using slave's enumeration address.
>> +               (e.g. in the example below, slave's name will be:
>> +               0x217:0x60:0x1:0x0)
> Are devices discoverable and uniquely identifiable? This would be
> something like a VID/PID which can be read in a generic way. It looks
> like the address contains this info, but can you discover the
> addresses of devices on the bus? If not compatible should not be
> optional.
Yes, as Mark pointed out in another thread, it's enumerable but more 
likely to need the compatible field for binding to make the device 
functional.
I will word this accordingly.
>
>> +
>> +SLIMbus example for Qualcomm's slimbus manager compoent:
> typo.
>
>> +
>> +       slim@28080000 {
>> +               compatible = "qcom,slim-msm";
>> +               reg = <0x28080000 0x2000>,
>> +               reg-names = "slimbus_physical";
> Pretty pointless to have names with a single element.
I missed 1 more name typically used by the controller in this example. 
Will update that.
>
>> +               interrupts = <0 33 0>;
>> +               interrupt-names = "slimbus_irq";
>> +               clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
>> +               clock-names = "iface_clk", "core_clk";
>> +
>> +               slim_codec_slave {
> You should have unit address here. Probably with "." in between fields
> of the address that have defined meaning. So that may be something
> like "0217.0060.01.00" based on what you do with the address bytes
> below.
Yes, that's a good idea and will go well when unit address and reg will 
have same 4 fields.

Thanks for the review-
Sagar
>
>> +                       reg = <00 01 60 00 17 02>;
>> +               };
>> +       };
>> diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
>> index ee80c1b..d3fa28b 100644
>> --- a/drivers/slimbus/slim-core.c
>> +++ b/drivers/slimbus/slim-core.c
>> @@ -18,6 +18,7 @@
>>   #include <linux/idr.h>
>>   #include <linux/pm_runtime.h>
>>   #include <linux/slimbus.h>
>> +#include <linux/of.h>
>>
>>   static DEFINE_MUTEX(slim_lock);
>>   static DEFINE_IDR(ctrl_idr);
>> @@ -289,6 +290,79 @@ static LIST_HEAD(board_list);
>>   static LIST_HEAD(slim_ctrl_list);
>>   static DEFINE_MUTEX(board_lock);
>>
>> +#if IS_ENABLED(CONFIG_OF)
>> +/* OF helpers for SLIMbus */
>> +static void of_register_slim_devices(struct slim_controller *ctrl)
>> +{
>> +       struct device_node *node;
>> +       struct slim_boardinfo *temp, *binfo = NULL;
>> +       int n = 0;
>> +
>> +       if (!ctrl->dev.of_node)
>> +               return;
>> +
>> +       for_each_child_of_node(ctrl->dev.of_node, node) {
>> +               int ret;
>> +               u32 ea[6];
>> +               struct slim_device *slim;
>> +               char *name;
>> +
>> +               ret = of_property_read_u32_array(node, "reg", ea, 6);
>> +               if (ret) {
>> +                       dev_err(&ctrl->dev, "of_slim: E-addr err:%d\n", ret);
>> +                       continue;
>> +               }
>> +               name = kcalloc(SLIMBUS_NAME_SIZE, sizeof(char), GFP_KERNEL);
>> +               if (!name)
>> +                       goto of_slim_err;
>> +
>> +               slim = kzalloc(sizeof(struct slim_device), GFP_KERNEL);
>> +               if (!slim) {
>> +                       kfree(name);
>> +                       goto of_slim_err;
>> +               }
>> +               slim->e_addr.manf_id = (u16)((ea[5] << 8) | ea[4]);
>> +               slim->e_addr.prod_code = (u16)((ea[3] << 8) | ea[2]);
>> +               slim->e_addr.dev_index = (u8)ea[1];
>> +               slim->e_addr.instance = (u8)ea[0];
>> +
>> +               ret = of_modalias_node(node, name, SLIMBUS_NAME_SIZE);
>> +               if (ret < 0) {
>> +                       /* use device address for name, if not specified */
>> +                       snprintf(name, SLIMBUS_NAME_SIZE, "0x%x:0x%x:0x%x:0x%x",
>> +                                slim->e_addr.manf_id, slim->e_addr.prod_code,
>> +                                slim->e_addr.dev_index, slim->e_addr.instance);
>> +               }
>> +
>> +               temp = krealloc(binfo, (n + 1) * sizeof(struct slim_boardinfo),
>> +                                       GFP_KERNEL);
>> +               if (!temp) {
>> +                       kfree(name);
>> +                       kfree(slim);
>> +                       goto of_slim_err;
>> +               }
>> +               binfo = temp;
>> +               slim->dev.of_node = of_node_get(node);
>> +               slim->name = name;
>> +               binfo[n].bus_num = ctrl->nr;
>> +               binfo[n].slim_slave = slim;
>> +               n++;
>> +       }
>> +       slim_register_board_info(binfo, n);
>> +       return;
>> +
>> +of_slim_err:
>> +       n--;
>> +       while (n >= 0) {
>> +               kfree(binfo[n].slim_slave->name);
>> +               kfree(binfo[n].slim_slave);
>> +       }
>> +       kfree(binfo);
>> +}
>> +#else
>> +static void of_register_slim_devices(struct slim_controller *ctrl) { }
>> +#endif
>> +
>>   /* If controller is not present, only add to boards list */
>>   static void slim_match_ctrl_to_boardinfo(struct slim_controller *ctrl,
>>                                           struct slim_boardinfo *bi)
>> @@ -338,6 +412,7 @@ static void slim_ctrl_add_boarddevs(struct slim_controller *ctrl)
>>   {
>>          struct sbi_boardinfo *bi;
>>
>> +       of_register_slim_devices(ctrl);
>>          mutex_lock(&board_lock);
>>          list_add_tail(&ctrl->list, &slim_ctrl_list);
>>          list_for_each_entry(bi, &board_list, list)
>> --
>> 1.8.2.1
>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  parent reply	other threads:[~2015-08-06 19:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-03  6:59 [PATCH V3 0/6] Introduce framework for SLIMbus device drivers Sagar Dharia
2015-08-03  6:59 ` [PATCH V3 1/6] SLIMbus: Device management on SLIMbus Sagar Dharia
2015-08-14 18:17   ` Mark Brown
2015-08-03  6:59 ` [PATCH V3 2/6] of/slimbus: OF helper for SLIMbus Sagar Dharia
2015-08-03 16:13   ` Rob Herring
2015-08-04 17:27     ` Mark Brown
2015-08-06 19:10     ` Sagar Dharia [this message]
2015-08-03  6:59 ` [PATCH V3 3/6] slimbus: Add messaging APIs to slimbus framework Sagar Dharia
2015-08-14 18:25   ` Mark Brown
2015-08-14 18:33     ` Mark Brown
2015-08-03  6:59 ` [PATCH V3 4/6] slim: qcom: Add Qualcomm Slimbus controller driver Sagar Dharia
2015-08-14 18:31   ` Mark Brown
     [not found]     ` <20150814183106.GE10748-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-08-17 23:44       ` Sagar Dharia
2015-08-03  6:59 ` [PATCH V3 5/6] slimbus: Add support for 'clock-pause' feature Sagar Dharia
2015-08-14 18:39   ` Mark Brown
2015-08-17 23:43     ` Sagar Dharia
2015-08-03  6:59 ` [PATCH V3 6/6] slim: qcom: Add runtime-pm support using clock-pause feature Sagar Dharia
2015-08-14 18:43   ` Mark Brown
2015-08-14 18:46 ` [PATCH V3 0/6] Introduce framework for SLIMbus device drivers Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C3B13E.3050108@codeaurora.org \
    --to=sdharia@codeaurora.org \
    --cc=alan@linux.intel.com \
    --cc=andreas.noever@gmail.com \
    --cc=bp@suse.de \
    --cc=broonie@kernel.org \
    --cc=daniel.thompson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gong.chen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=james.hogan@imgtec.com \
    --cc=jkosina@suse.cz \
    --cc=joe@perches.com \
    --cc=kheitke@aud \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=michael.opdenacker@free-electrons.com \
    --cc=oded.gabbay@amd.com \
    --cc=pawel.moll@arm.com \
    --cc=poeschel@lemonage.de \
    --cc=robh+dt@kernel.org \
    --cc=robherring2@gmail.com \
    --cc=sharon.dvir1@mail.huji.ac.il \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).