+static int __init da850_evm_pruss_can_setup(void)
+{
+ int ret, val = 0;
+ void __iomem *cfg_chip3_reg;
+
+ ret = davinci_cfg_reg_list(da850_evm_pruss_can_pins);
+ if (ret)
+ pr_warning("%s: da850_evm_pruss_can_pins mux setup "
+ "failed:%d\n", __func__, ret);
Yet you continue to initializ
On Wed, Apr 27, 2011 at 09:29:59AM +0200, Marc Kleine-Budde wrote:
> On 04/27/2011 08:39 AM, Subhasish Ghosh wrote:
> > - Is it ok to have u32 etc for __iomem cookie ?
>
> no - "void __iomem *" is "void __iomem *"
Actually, it is _provided_ you don't directly dereference it. You can
then do poin
Hello.
On 27-04-2011 10:43, Subhasish Ghosh wrote:
#include
@@ -73,6 +75,7 @@ extern unsigned int da850_max_speed;
#define DA8XX_DDR2_CTL_BASE 0xb000
#define DA8XX_ARM_RAM_BASE 0x
#define DA8XX_SHARED_RAM_BASE 0x8000
+#define DA8XX_PRUSS_MEM_BASE 0x01C3
Keep the list sort
#include
@@ -73,6 +75,7 @@ extern unsigned int da850_max_speed;
#define DA8XX_DDR2_CTL_BASE 0xb000
#define DA8XX_ARM_RAM_BASE 0x
#define DA8XX_SHARED_RAM_BASE 0x8000
+#define DA8XX_PRUSS_MEM_BASE 0x01C3
Keep the list sorted please. Also, this macro doesn't seem used outside
On Wed, Apr 27, 2011 at 10:53:38, Subhasish Ghosh wrote:
> >> There should be no build time dependency with this patch
> >> (the above patch just changes which pool of SRAM the
> >> allocation happens from)
> >>
> >> But, this brings out an important dependency of the patch
> >> calling platform sp
- Use just *one* value per sysfs file
SG - I felt adding entry for each mbx_id will clutter the sysfs.
Is it ok to do that.
+static u32 pruss_intc_init[19][3] = {
+ {PRUSS_INTC_POLARITY0, PRU_INTC_REGMAP_MASK, 0x},
+ {PRUSS_INTC_POLARITY1, PRU_INTC_REGMAP_MASK, 0x},
+
>> >>The driver should probably just get sram
>> space through platform data so that it doesn't depend on the
>> platform specific sram allocation function.
Are you suggesting that I go back to that implementation.
No, the platform code should use the SRAM allocator and
pass on the allocated m
On Friday 22 April 2011, Subhasish Ghosh wrote:
> This patch adds the pruss MFD driver and associated include files.
> For details regarding the PRUSS please refer the folowing link:
> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
>
> The rational behind the MFD driv
My problem is, I am doing something like this:
s32 pruss_writel_multi(struct device *dev, u32 offset,
u32 *pdatatowrite, u16 wordstowrite)
{
struct pruss_priv *pruss = dev_get_drvdata(dev->parent);
u32 __iomem *paddresstowrite;
u16 i;
paddresstowrite =
On Wednesday 27 April 2011, Subhasish Ghosh wrote:
> >
> > - Use just one value per sysfs file
>
> SG - I felt adding entry for each mbx_id will clutter the sysfs.
> Is it ok to do that.
That is probably not much better either.
Note also that every sysfs file needs to come with associate
PRU's resulting in improved load sharing.
Signed-off-by: Subhasish Ghosh
Hi Subhasish,
This looks like great progress since the last time I looked at the
pruss mfd driver, good work there!
Thanks to your explanations and the documentation link, I now have
a better understanding of what is a
On Wednesday 27 April 2011, Subhasish Ghosh wrote:
> >
> > If I read your code correctly, you hardwire the usage of the two
> > PRUs in the da850 board code, which makes it impossible to use
> > them in different ways even if the hardware supports it. If this is
> > indeed the case, using an MFD de
Introduction
This is the proposal of the initial version of design and implementation of
the DM365 VPFE (Video Port Front End) drivers
using Media Controloler , the initial version which supports
the following:
1) dm365 vpfe
2) ccdc,previewer,resizer,h3a,af blocks
3) supports both con
Hi Subhasish,
On Wed, Apr 27, 2011 at 18:45:06, Subhasish Ghosh wrote:
> >> >>The driver should probably just get sram
> >> >> space through platform data so that it doesn't depend on the
> >> >> platform specific sram allocation function.
> >>
> >> Are you suggesting that I go back to that imple
Hi Ben,
[CCing netdev maintainer]
On Thu, Apr 21, 2011 at 23:00:32, Ben Gardiner wrote:
> The current implementation of emac_rx_handler, when the host is
> flooded, will result in a great deal of WARNs on the console; due to
> the return value of cpdma_chan_submit. This function can error with
>
15 matches
Mail list logo
