On 10/20/2015 05:18 PM, Marc Kleine-Budde wrote:
> On 10/20/2015 05:09 PM, Anton.Glukhov wrote:
>>>> It's OMAP3 based arch, but HECC is implemented only in AM3505 and AM3517
>>>> SoCs.
>>>> So, I'm confused about what's "name"
.
> What do you mean available? I know only that HECC appear in AM3505 and
> AM3517. Nowhere else.
Available on the market. Which one was produced first or was soldered
first to some PCB?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Sol
On 10/20/2015 04:57 PM, Anton.Glukhov wrote:
> Hello Marc, Heiko!
> I'm sorry for the delay!
>
> On 19.10.2015 10:31, Marc Kleine-Budde wrote:
>> On 10/19/2015 09:27 AM, Heiko Schocher wrote:
>>>>> .../devicetree/bindings/net/can/ti_hecc-can.txt| 2
; + ti,hecc_ram_offset = <0x3000>;
>>> + ti,hecc_mbx_offset = <0x2000>;
>>> + ti,hecc_int_line = <0>;
>>> + ti,hecc_version = <1>;
>>
>> Versioning in the OF world is done via the compatible. Are the off
; static int ti_hecc_probe(struct platform_device *pdev)
> {
> struct net_device *ndev = (struct net_device *)0;
> struct ti_hecc_priv *priv;
> - struct ti_hecc_platform_data *pdata;
> + const struct ti_hecc_platform_data *pdata;
> struct reso
On 07/09/2015 08:34 PM, Marc Kleine-Budde wrote:
> On 07/07/2015 04:27 PM, Roger Quadros wrote:
>> Driver core sets "default" pinmux on on probe and CAN driver
>> sets "sleep" pinmux during register. This causes a small window
>> where the CAN pins ar
led.
>
> Change the "default" state to be like sleep so this glitch is
> avoided. Add a new "active" state that is used by the driver
> when CAN is actually active.
Who is taking care of this patch? I'm applying 1/2 (v2) to linux-can,
should I take th
else use "default" */
>> +p = pinctrl_get_select(priv->device, "active");
>> +if (!IS_ERR(p))
>> +pinctrl_put(p);
>> +else
>> +pinctrl_pm_select_default_state(priv->device);
>> +
>
> Thanks. T
help. This patch by itself won't fix anything.
> It needs to go in together with the DTS change in patch 2.
Of course.
> Maybe if Tony can Ack the second patch then both should be applicable
> on v4.0+ for stable.
Marc
--
Pengutronix e.K. | Marc Kleine-Bu
t;>>> +#ifdef CONFIG_PINCTRL
>>>
>>> Please remove the ifdef, AFAICS there are static inline noop functions
>>> if CONFIG_PINCTRL switched off.
>>
>> yes, you are right.
>
> On second thoughts
>
> device->pins are
empt to use "active" if available else use "default" */
> + s = pinctrl_lookup_state(priv->device->pins->p, "active");
> + if (!IS_ERR(s))
> + pinctrl_select_state(priv->device->pins->p, s);
> + el
1 to clear it.
>
> So we defer the clearing of DONE bit to later when we set the START bit.
> There we are sure that START bit is changed from 0 to 1 so the write of
> 1 to already set DONE bit will happen.
>
> Signed-off-by: Roger Quadros
Applied to linux-can.
Thanks, Marc
n states, with semantics as defined in
> *
> */
> dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
> PINCTRL_STATE_SLEEP);
>
> So if these states are necessary for the driver to work, put
> depends on PM
0b81cd5607e51
> Even without this second patch DCAN seems to work.
FWIW:
Acked-by: Marc Kleine-Budde
I've send a pull request with the CAN driver changes to David Miller
yesterday, the code is supposed to hit mainline in v3.19.
regards,
Marc
--
Pengutronix e.K. | Marc K
On 11/17/2014 03:19 PM, Roger Quadros wrote:
> On 11/17/2014 02:31 PM, Roger Quadros wrote:
>> On 11/17/2014 02:12 PM, Marc Kleine-Budde wrote:
>>> On 11/17/2014 01:09 PM, Roger Quadros wrote:
>>>> AM4372 SoC has 2 DCAN modules. Add compatible id and
>>>&
ta = &d_can_drvdata },
> { .compatible = "ti,dra7-d_can", .data = &dra7_dcan_drvdata },
> { .compatible = "ti,am3352-d_can", .data = &am3352_dcan_drvdata },
> + { .compatible = "ti,am4372-d_can", .data = &am3352_dcan_drvdata },
>
On 11/17/2014 12:17 PM, Roger Quadros wrote:
>> I'll send an updated series.
>
> Looks better. Thanks.
Can you make a quick test with the new series on real hardware.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutio
From: Roger Quadros
DRA7 SoC has 2 CAN IPs. Provide compatible IDs and RAMINIT
register data for both.
Signed-off-by: Roger Quadros
Signed-off-by: Marc Kleine-Budde
---
Documentation/devicetree/bindings/net/can/c_can.txt | 1 +
drivers/net/can/c_can/c_can_platform.c | 13
From: Roger Quadros
Some platforms (e.g. TI) need special RAMINIT register handling.
Provide a way to store RAMINIT register description in driver data.
Signed-off-by: Roger Quadros
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/c_can/c_can.h | 10 ++
1 file changed, 10
RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: Roger Quadros
Signed-off-by: Marc Kleine-Budde
---
.../devicetree/bindings/net/can/c_can.txt | 3 +
drivers/net/can/c_can/c_can.h | 10
DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/c_can/c_can.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can
From: Roger Quadros
AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: Roger Quadros
Acked-by: Wolfram Sang
Signed-off-by: Marc Kleine-Budde
---
Documentation/devicetree/bindings/net/can/c_can.txt | 2 +-
drivers/net/can/c_can
Quadros
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/c_can/c_can.h | 4 +++
drivers/net/can/c_can/c_can_platform.c | 52 +++---
2 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
Picking up Roger's work:
Changes since v7:
- combined raminit start and done bit into a struct (3/8, 7/8, 8/8)
- constified struct c_can_driver_data (2/8, 7/8, 8/8)
- silenced compiler warning in c_can_hw_raminit_{wait,}_syscon (4/8)
- use platform_get_device_id in probe() instead of open coding i
From: Roger Quadros
Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status.
Signed-off-by: Roger Quadros
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/c_can/c_can.h | 1
t an error message.
Signed-off-by: Roger Quadros
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/c_can/c_can_platform.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index fb
.raminit_bits = dra7_raminit_bits,
+ .raminit_pulse = true,
+};
I'll send an updated series.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-2069
te(raminit->syscon, raminit->reg, ctrl);
> +
> + ctrl |= 1 << done_bit;
> + c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
> }
> spin_unlock(&raminit_lock);
> }
My arm gcc-4.7.2 spits this warnings, I'll initialize ctrl to 0.
> drivers/net/can/c_can/c_can_platform.c: In function
> 'c_can_hw_raminit_wait_syscon':
> drivers/net/can/c_can/c_can_platform.c:92:17: warning: 'ctrl' may be used
> uninitialized in this function [-Wuninitialized]
> drivers/net/can/c_can/c_can_platform.c: In function 'c_can_hw_raminit_syscon':
> drivers/net/can/c_can/c_can_platform.c:115:7: warning: 'ctrl' is used
> uninitialized in this function [-Wuninitialized]
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
^
Replaced by ARRAY_SIZE(dra7_raminit_start_bits)
Same for the am3352_dcan_drvdata in the next patch.
> + .raminit_start_bits = dra7_raminit_start_bits,
> + .raminit_done_bits = dra7_raminit_done_bits,
> + .raminit_pulse = true,
> +};
Marc
--
Pengutronix e.K.
,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
am Sang
For the whole series or just this patch?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA
> dev->flags |= IFF_ECHO; /* we support local echo */
> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
> index c6715ca..3cedf48 100644
> --- a/drivers/net/can/c_can/c_can.h
> +++ b/drivers/net/can/c_can/c_can.h
> @@ -210,6 +210,7 @@ struct c_c
On 11/13/2014 03:49 PM, Roger Quadros wrote:
> On 11/13/2014 04:44 PM, Marc Kleine-Budde wrote:
>> On 11/13/2014 03:40 PM, Roger Quadros wrote:
>>> On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
>>>> On 11/13/2014 01:22 PM, Roger Quadros wrote:
>>>>&
On 11/13/2014 03:40 PM, Roger Quadros wrote:
> On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
>> On 11/13/2014 01:22 PM, Roger Quadros wrote:
>>> The SoC contains 2 DCAN modules. Add them.
>>>
>>> Signed-off-by: Roger Quadros
>>>
clocks = <&dcan1_fck>;
> + clock-names = "fck";
> + reg = <0x481d 0x2000>;
> + syscon-raminit = <&am43xx_control_module 0x644 1>;
> + interrupts = ;
> + st
ch Tony will take as
> we don't see
> any DT binding changes.
Alright then (I'll give your email to $CUSTOMERS complaining ;) ), this
whole series will go into 3.19.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions|
"failed to get pinctrl\n");
> + }
Can you move the initial setting into c_can.c, register_c_can_dev()
should be a good candidate.
> +
> /* get the appropriate clk */
> clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(clk)
* if not specified in DT.
> + /* Check if we need custom RAMINIT via syscon. Mostly for TI
> + * platforms. Only supported with DT boot.
> */
> - if (!res) {
> + if (np && of_property_read_bool(np, "sys
g init routines or create regmap
in the platform driver an use the new ones.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsg
s/net/can/c_can/c_can_platform.c
> index 1546c2b..20deb67 100644
> --- a/drivers/net/can/c_can/c_can_platform.c
> +++ b/drivers/net/can/c_can/c_can_platform.c
> @@ -250,6 +250,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
> }
>
> priv = netdev_pri
^^
I've changes this to platform_get_device_id() while aplying.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
nctrl, s);
> + }
Please put this common code into a seperate function.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
On 11/05/2014 02:36 PM, Roger Quadros wrote:
> On 11/05/2014 03:30 PM, Marc Kleine-Budde wrote:
>> On 11/04/2014 11:21 AM, Roger Quadros wrote:
>>> DRA7 SoC has 2 CAN IPs. Provide compatible IDs and RAMINIT
>>> register data for both.
>>
>> My understan
struct of_device_id c_can_of_table[] = {
> { .compatible = "bosch,c_can", .data = &c_can_drvdata },
> { .compatible = "bosch,d_can", .data = &d_can_drvdata },
> + { .compatible = "ti,dra7-d_can1", .data = &dra7_dcan1_drvdata }
;pinctrl, s);
> + }
Can you factor this into a common function? Which is used like this:
c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT)
Otherwise looks god.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone:
On 10/01/2014 12:43 PM, Wolfram Sang wrote:
> compatible = "commodore,c64ultra", "bosch,d_can";
\o/
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund
>
> Is it OK to create a new platform_data structure for CAN and put the type and
> raminit start/stop
> bits there?
Yes, have a look how it's handled in the flexcan driver.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industria
On 10/01/2014 12:12 PM, Roger Quadros wrote:
> On 10/01/2014 01:01 PM, Marc Kleine-Budde wrote:
>> On 10/01/2014 11:06 AM, Roger Quadros wrote:
>>> On 10/01/2014 11:47 AM, Marc Kleine-Budde wrote:
>>>> On 10/01/2014 10:45 AM, Roger Quadros wrote:
>>>>&
On 10/01/2014 11:06 AM, Roger Quadros wrote:
> On 10/01/2014 11:47 AM, Marc Kleine-Budde wrote:
>> On 10/01/2014 10:45 AM, Roger Quadros wrote:
>>> On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote:
>>>> On 09/30/2014 05:25 PM, Wolfram San
On 10/01/2014 10:45 AM, Roger Quadros wrote:
> On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote:
>> On 09/30/2014 05:25 PM, Wolfram Sang wrote:
>>>
>>>> Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for
>>>> additional parameters.
t;
> Agreed. I thought we had this information in the driver already, but we
> haven't...
>
The current driver relies on the of_alias_get_id(), which isn't
considered best practice, is it? So I want to avoid this when switching
to syscon.
Marc
--
Pengutronix e.K.
On 09/30/2014 04:49 PM, Wolfram Sang wrote:
> On Tue, Sep 30, 2014 at 04:22:08PM +0200, Marc Kleine-Budde wrote:
>> On 09/30/2014 04:19 PM, Wolfram Sang wrote:
>>>
>>>> As just TI is using this out of band RAMINIT mechanism, should it be
>>>> "ti
refer a more precise property like "syscon-raminit" to allow
> for further syscon extensions later or something...
What do you think about putting the bit information in the
syscon-raminit phandle as additional arguments?
Marc
--
Pengutronix e.K. | Marc Klein
On 09/30/2014 04:02 PM, Roger Quadros wrote:
> On 09/30/2014 04:45 PM, Marc Kleine-Budde wrote:
>> On 09/30/2014 03:26 PM, Wolfram Sang wrote:
>>> On Tue, Sep 09, 2014 at 05:31:09PM +0300, Roger Quadros wrote:
>>>> Some TI SoCs like DRA7 have a RAMINIT register spe
should not be encoded in DT! This is not describing hardware setup.
> The driver should know where the bits are for the syscon phandle,
> depending on which SoC it runs...
Is the register shared by more than one core? If so the information has
to go somewhere. Using an alias in the DT is pr
On 09/09/2014 04:39 PM, Roger Quadros wrote:
> On 09/09/2014 05:34 PM, Marc Kleine-Budde wrote:
>> On 09/09/2014 04:31 PM, Roger Quadros wrote:
>>> Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
>>> They seem to have been swap
cks = <&dcan1_fck>;
> + clock-names = "fck";
> + reg = <0x481d 0x2000
> + 0x44e10644 0x4>;
> + interrupts = ;
> + status = "disabled";
&
ng boot.
With your patch set this is not true anymore, is it?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hil
On 09/09/2014 05:04 PM, Marc Kleine-Budde wrote:
> On 09/09/2014 04:55 PM, Roger Quadros wrote:
>> The SoC supports 2 DCAN nodes. Add them.
>
> I think you should put the device-tree ml for DT related patches on Cc.
>
>>
>> Signed-off-by: Roger Quadros
>>
48 0x2000>,
> + <0x558 0x4>; /* index to RAMINIT reg within
> syscon */
> + ti,raminit-syscon = <&dra7_ctrl_core>;
> + ti,raminit-start-bit = <5>;
> + ti,raminit-done-bit = <2>;
> +
buggy and may not always be
> set after the START bit is set. So add a timeout mechanism to
> c_can_hw_raminit_wait_ti().
What should happen if the timeout occurs?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231
> to TI platforms.
>
> I don't mind vendor prefix or not, but would like to hear the opinion of the
> CAN maintainers as to what they would prefer.
I don't know of any c_can/d_can implementation outside of TI that
implements the raminit outside of the register space. So a &q
e.
I was assuming you're already on DT only :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildeshe
On 03/12/2013 04:20 PM, Roger Quadros wrote:
> On 03/12/2013 04:42 PM, Marc Kleine-Budde wrote:
>> On 03/12/2013 03:28 PM, Roger Quadros wrote:
>>> On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote:
>>>> On 03/12/2013 03:12 PM, Roger Quadros wrote:
>>>>&
On 03/12/2013 03:28 PM, Roger Quadros wrote:
> On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote:
>> On 03/12/2013 03:12 PM, Roger Quadros wrote:
>>> On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote:
>>>> On 03/12/2013 12:24 PM, Roger Quadros wrote:
>>>>>
On 03/12/2013 03:12 PM, Roger Quadros wrote:
> On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote:
>> On 03/12/2013 12:24 PM, Roger Quadros wrote:
>>> Add clk_rate parameter to platform data. If supplied, the
>>> NOP phy driver will program the clock to that rate durin
nd
> then the driver will bail out with -EPROBE_DEFER.
Is there a platform which fills out pdata.needs_vcc and
pdata.needs_reset? IMHO it makes no sense to add features for the non DT
case, if there isn't any user for it.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde
gle u32. Someone correct me if I'm wrong.
>>
>
> Yes you are right. Kishon was asking me to use u8 instead of unsigned int,
> which
> I don't think is necessary. AFAIK, it is a norm to use unsigned int when
> defining
> a bitfield. Compilers are known to behave f
On 03/11/2013 09:40 AM, Roger Quadros wrote:
> On 03/08/2013 05:45 PM, Marc Kleine-Budde wrote:
>> On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
>>> On 02/04/2013 04:58 PM, Roger Quadros wrote:
>>>> The PHY clock, clock rate, VCC regulator and RESET regulator
>&
be(struct platform_device
>> *pdev)
>> if (!nop->phy.otg)
>> return -ENOMEM;
>>
>> +if (dev->of_node) {
>> +pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> +
On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
> On 02/04/2013 04:58 PM, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> .../de
e:
> +
> + hsusb1_phy {
> + compatible = "usb-nop-xceiv";
> + clock-frequency = <1920>;
Why do you hardcode the clock frequency here? You should use
clk_get_rate() to get the frequency from the clock tree.
Marc
--
Pengutronix e.K.
it's good if he has a vision
>> how things should be lined out.
>>
>> In practice, there is little difference between a 'bus_type' and a 'class',
>> so just replace any instance of the former with the latter in your head
>> when reading the code
usb_phy *phy = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> +
> + phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
> + if (IS_ERR(phy)) {
You should probably lock the phy module in memory. See my patch "usb:
otg:
uct device *dev, struct usb_phy *x);
> +extern int usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name);
> #else
> static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
> {
> @@ -171,6 +188,11 @@ static inline void devm_usb
On 11/21/2012 11:07 AM, AnilKumar, Chimata wrote:
> On Wed, Nov 21, 2012 at 15:01:22, Marc Kleine-Budde wrote:
>> From: AnilKumar Ch
>>
>> Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
>> which holds all the message objects during transmission or
profile#1.
Signed-off-by: AnilKumar Ch
[mkl: fix instance for non DT in probe, cleaned up raminit]
Signed-off-by: Marc Kleine-Budde
---
Hello,
compile time tested only - please test on real HW.
changes since v2
- rename member in c_can_priv to raminit
(to be consistent with the rest of the driver
p;pdev->dev, res);
> + if (!priv->raminit_ctrlreg || priv->instance < 0) {
> + dev_info(&pdev->dev, "control memory is not used for
> raminit\n");
> + break;
> + }
> + priv->ram_init
>raminit_ctrlreg);
> + if (enable) {
> + val &= ~CAN_RAMINIT_START_MASK(priv->instance);
What's the point of clearing the bit first?
> + val |= CAN_RAMINIT_START_MASK(priv->instance);
> + writel(val, priv->raminit_ctrlreg);
On 11/21/2012 06:45 AM, AnilKumar, Chimata wrote:
> On Tue, Nov 20, 2012 at 15:56:32, Marc Kleine-Budde wrote:
>> On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote:
>>> On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote:
>>>> On 11/14/2012 07:08 PM, AnilK
added
> to d_can driver.
>
> Signed-off-by: AnilKumar Ch
Acked-by: Marc Kleine-Budde
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
NULL then devm_xx will return
> NULL which result into printing of below warning.
>
>>
>>> + if (!priv->raminit_ctrlreg)
>>> + dev_warn(&pdev->dev, "failed to obtain control
>>> memory\n");
>
> I will change
ias_get_id() gives the device id number based
> on number of alias nodes present in "aliases node".
>
> Signed-off-by: AnilKumar Ch
Acked-by: Marc Kleine-Budde
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone:
;raminit_ctrlreg)
> + dev_warn(&pdev->dev, "failed to obtain control
> memory\n");
> +
> + if (pdev->dev.of_node)
> + pdev->id = of_alias_get_id(pdev->dev.of_node, "d_can");
> +
> +
On 11/20/2012 11:23 AM, AnilKumar, Chimata wrote:
> On Tue, Nov 20, 2012 at 15:43:04, Marc Kleine-Budde wrote:
>> On 11/14/2012 07:08 PM, AnilKumar Ch wrote:
>>> Add a new address space/memory resource to d_can device tree node. D_CAN
>>> RAM initialization is achiev
0003 ARM: dts: AM33XX: Add memory resource to d_can node
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA
ser binds to mulitple phys.
>
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend,
> resume,
> poweron, shutdown.
>
> Cc: Felipe Balbi
> Cc: Marc Kleine-Budde
> Signed-off-b
ion I suggest to create a struct phy_res. For now
its only member will be a pointer to a struct phy.
>
> ...
>
>>> +
>>> + ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
>>
>> Is this the right size?
>>
>> Because ptr is
On 09/26/2012 11:20 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Mon, Sep 17, 2012 at 3:03 PM, Marc Kleine-Budde
> wrote:
>> On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
>>
>> [...]
>>
>>>>> diff --git a/drivers/phy/phy-core.c
like this would be required for USB support
> on beagle bone (AM335X), which has 2 phy's of same type.
>
> Or is the plan to use generic phy framework instead ?
Yes, Kishon's patches look more generic than mine.
Marc
[2] https://patchwork.kernel.org/patch/1457801/
--
On 09/19/2012 04:42 PM, Felipe Balbi wrote:
> On Wed, Sep 19, 2012 at 04:45:01PM +0200, Marc Kleine-Budde wrote:
>> On 09/19/2012 01:56 PM, Felipe Balbi wrote:
>>> On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
>>>> "usb_otg_ss_refclk960
dev_err(&pdev->dev, "unable to get refclk960m\n");
>> +return PTR_ERR(phy->optclk);
>> +}
>> +clk_prepare(phy->optclk);
>> +}
>
> instead, can't you just always try to
+#define PLL_REGM_F_MASK 0x0003
> +#define PLL_REGM_F_SHIFT0x0
> +#define PLL_REGN_MASK 0x01FE
> +#define PLL_REGN_SHIFT 0x1
> +#define PLL_SELFREQDCO_MASK 0x000E
> +#define PLL_SELFREQDCO_SHIFT0x1
> +#define
gt;>> +
>>> + node = of_parse_phandle(dev->of_node, phandle, 0);
BTW: Is the node freed somewhere?
>>> + if (!node) {
>>> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
>>> +
n struct phy *devm_of_phy_get(struct device *dev, const char *phandle);
> +extern struct phy *phy_get(struct device *dev, u8 index);
> +extern void phy_put(struct phy *phy);
> +extern struct phy *create_phy(struct device *dev, struct phy_descriptor
> *desc);
> +extern void destroy_phy(struct phy *phy);
> +extern struct phy_bind *phy_bind(const char *dev_name, u8 index,
> + const char *phy_dev_name);
> +#else
> +static inline struct phy *devm_phy_get(struct device *dev, u8 index)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> +
> +static inline void devm_phy_put(struct device *dev, struct phy *phy)
> +{
> +}
> +
> +static inline struct phy *devm_of_phy_get(struct device *dev,
> + const char *phandle)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> +
> +static inline struct phy *phy_get(struct device *dev, u8 index)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> +
> +static inline void phy_put(struct phy *phy)
> +{
> +}
> +
> +static inline struct phy *create_phy(struct device *dev,
> + struct phy_descriptor *desc)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> +
> +static inline void destroy_phy(struct phy *phy)
> +{
> +}
> +
> +static inline struct phy_bind *phy_bind(const char *dev_name, u8 index,
> + const char *phy_dev_name)
> +{
> +}
> +#endif
> +
> +static inline int phy_init(struct phy *phy)
> +{
> + if (phy->desc->ops->init)
> + return phy->desc->ops->init(phy->desc);
> +
> + return -EINVAL;
> +}
> +
> +static inline int phy_exit(struct phy *phy)
> +{
> + if (phy->desc->ops->exit)
> + return phy->desc->ops->exit(phy->desc);
> +
> + return -EINVAL;
> +}
> +
> +static inline int phy_suspend(struct phy *phy)
> +{
> + if (phy->desc->ops->suspend)
> + return phy->desc->ops->suspend(phy->desc);
> +
> + return -EINVAL;
> +}
> +
> +static inline int phy_resume(struct phy *phy)
> +{
> + if (phy->desc->ops->resume)
> + return phy->desc->ops->resume(phy->desc);
> +
> + return -EINVAL;
> +}
> +
> +static inline int phy_poweron(struct phy *phy)
> +{
> + if (phy->desc->ops->poweron)
> + return phy->desc->ops->poweron(phy->desc);
> +
> + return -EINVAL;
> +}
> +
> +static inline void phy_shutdown(struct phy *phy)
> +{
> + if (phy->desc->ops->shutdown)
> + phy->desc->ops->shutdown(phy->desc);
> +}
> +#endif /* __DRIVERS_PHY_H */
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
might be NULL. AFAICS pm_runtime_get() is not safe to
be called with a NULL pointer.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
On 09/13/2012 09:24 AM, AnilKumar, Chimata wrote:
> Marc,
>
> On Wed, Sep 12, 2012 at 18:32:53, Marc Kleine-Budde wrote:
>> On 09/12/2012 02:48 PM, AnilKumar, Chimata wrote:
>>> Hi Marc,
>>>
>>> On Tue, Sep 04, 2012 at 12:57:18, Marc Kleine-Budde wro
p;pdev->dev);
When squaahsing both patches we see still some changes here, I'll fix
that, too.
> exit_free_device:
> free_c_can_dev(dev);
> exit_iounmap:
> @@ -239,7 +235,6 @@ static int __devexit c_can_plat_remove(struct
> platform_device *pdev)
> mem = platf
On 09/12/2012 02:48 PM, AnilKumar, Chimata wrote:
> Hi Marc,
>
> On Tue, Sep 04, 2012 at 12:57:18, Marc Kleine-Budde wrote:
>> On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote:
>>> Marc,
>>>
>>> Thanks for the comments,
>>>
>>> On Tue, S
On 09/06/2012 12:02 PM, AnilKumar Ch wrote:
> Modify c_can binding documentation according to recent review comments
> on device tree data addition patches.
>
> Signed-off-by: AnilKumar Ch
Thanks, I've updated my master branch.
Marc
--
Pengutronix e.K. |
1 - 100 of 126 matches
Mail list logo
