aintainers want to reduce (and perhaps
>even
eliminate) these board-specific constructs, and try to utilize common
driver-code that
resides in the "driver" folder. I can vouch for the syscon/regmap framework as
something
which would enable the effort.
Thanks,
Marc C
On 01/24/2014 10:23 AM,
have a
discontiguous memory-mapping, where a designer chooses not to populate physical
DRAM in
the middle.
The 'reg' property was broken-up to have each chunk of memory given a dedicated
memblock.
All that said, if you like, I can rework the patch as you've suggested.
Thanks,
Marc C
On 01/24/2014 03:
se.
>
>> +
>> +example:
>> +reboot {
>> +compatible = "brcm,brcmstb-reboot";
>> +syscon = <_top_ctrl 0x304 0x308>;
>> +};
>
> As with smpboot, this seems odd.
Sure. Our H/W designers unfortunately didn't put the boot and
ensure there aren't any magic requirements
unaccounted for.
Thank you for taking a deep-dive into the code! I'll make the appropriate
modifications
per your suggestions.
Regards,
Marc C
On 01/24/2014 02:14 AM, Mark Rutland wrote:
> On Wed, Jan 22, 2014 at 03:30:45AM +, Marc Carino wrote:
&g
modifications
per your suggestions.
Regards,
Marc C
On 01/24/2014 02:14 AM, Mark Rutland wrote:
On Wed, Jan 22, 2014 at 03:30:45AM +, Marc Carino wrote:
The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
This patch adds machine support for the ARM-based Broadcom SoCs
into a
logical grouping, or standard register interface. Instead, they're all over the
place.
How do you suggest naming the nodes to indicate this?
Thanks,
Marc C
On 01/24/2014 03:03 AM, Mark Rutland wrote:
On Wed, Jan 22, 2014 at 03:30:50AM +, Marc Carino wrote:
Document the bindings
not to populate physical
DRAM in
the middle.
The 'reg' property was broken-up to have each chunk of memory given a dedicated
memblock.
All that said, if you like, I can rework the patch as you've suggested.
Thanks,
Marc C
On 01/24/2014 03:09 AM, Mark Rutland wrote:
On Wed, Jan 22, 2014 at 03:30
common
driver-code that
resides in the driver folder. I can vouch for the syscon/regmap framework as
something
which would enable the effort.
Thanks,
Marc C
On 01/24/2014 10:23 AM, Mark Rutland wrote:
On Fri, Jan 24, 2014 at 06:03:10PM +, Feng Kan wrote:
On Fri, Jan 24, 2014 at 3:39 AM
usters (like big.LITTLE).
Thanks,
Marc
On 01/23/2014 10:26 AM, Florian Fainelli wrote:
> Hi Marc,
>
> 2014/1/22 Marc C :
>> Hi Florian,
>>
>>> Do not we also need to update drivers/irqchip/irq-gic.c to look for
>>> this compatible property? Alternativ
for
now, and not have an entry in the efficiency table. There are currently no
BCM7xxx
platforms architected with heterogeneous multi-processing or multiple disparate
CPU
clusters (like big.LITTLE).
Thanks,
Marc
On 01/23/2014 10:26 AM, Florian Fainelli wrote:
Hi Marc,
2014/1/22 Marc C marc.cee
ies has the "compatible" string set exactly that way. I
was
following the pattern seen in the other reference DTS files, where
"arm,cortex-a15-gic" is
used as the fall-back.
Thanks,
Marc C
[1] https://lkml.org/lkml/2014/1/21/649
On 01/22/2014 02:40 PM, Florian Fainelli wro
that way. I
was
following the pattern seen in the other reference DTS files, where
arm,cortex-a15-gic is
used as the fall-back.
Thanks,
Marc C
[1] https://lkml.org/lkml/2014/1/21/649
On 01/22/2014 02:40 PM, Florian Fainelli wrote:
Hi Marc,
2014/1/21 Marc Carino marc.cee...@gmail.com:
Document
Hello Arnd,
> And then you can add a regular device driver to drivers/reset that provides a
> device_reset() API to other drivers, or a system-reset function to be
> registered as
> arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to
> get access
> to a regmap pointer,
Hello Arnd,
And then you can add a regular device driver to drivers/reset that provides a
device_reset() API to other drivers, or a system-reset function to be
registered as
arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to
get access
to a regmap pointer, and then
Hello Arnd,
> Do you have a strong reason to have your own defconfig file? We
> currently try to consolidate as much as possible into
> multi_v7_defconfig, so please see if you can extend that instead to
> do what you need.
There's no reason why we can't use the multi-platform defconfig. I'll
Hello Arnd,
Do you have a strong reason to have your own defconfig file? We
currently try to consolidate as much as possible into
multi_v7_defconfig, so please see if you can extend that instead to
do what you need.
There's no reason why we can't use the multi-platform defconfig. I'll
make
>> One thing which would probably be worthwhile tho is getting rid of the
>> bitmap based qc tag allocator in libata. That one is just borderline
>> stupid to keep around on any setup which is supposed to be scalable.
> Your border might be wider than mine :-). Yes, the bitmap should
> definitely
One thing which would probably be worthwhile tho is getting rid of the
bitmap based qc tag allocator in libata. That one is just borderline
stupid to keep around on any setup which is supposed to be scalable.
Your border might be wider than mine :-). Yes, the bitmap should
definitely go.
A
18 matches
Mail list logo
